This document discusses user stories and their use for writing requirements. It addresses some problems with overly relying on technical requirements, including lack of context. User stories follow a simple format of "As a <user type>, I want <goal> so that <benefit>" to help focus on the user perspective. The document provides some examples and emphasizes the value of writing requirements in a way that fits the specific needs of the project. It encourages trying new methods and adapting practices as needed.

2. Technical…
User Stories?!
Kasia Mrowca

4. Let’s start!

5. Technical requirements

6. Part of the product
Technical requirements

7. Part of the product Product
Technical requirements

8. Sins

9. Problem 1: Dependency

10. Source: http://geek-and-poke.com/

11. Problem 2: Road map

12. Problem 2: Road map
commitment

13. Problem 3: User Stories

14. Problem 3: User Stories
quality

15. AS A USER <WHO>
I WANT <WHAT>
SO THAT <WHY>

16. AS A SYSTEM USER I WANT
TO LOG IN TO BE LOGGED IN

17. AS A TOURIST I WANT
TO GET TICKET PRICES
FROM DIFFERENT AIRLINES SO THAT
I CAN COMPARE THE PRICES

18. Problem 4: acceptance
criteria

20. Improve?

21. WHY?
WHAT? WHO?

22. WHY?
WHAT? WHO?

23. WHY?Performance
Security
‘Communication’
Maintenance
Scalability
Other non functional requirements…

24. Write it down!

25. WHY?
WHAT? WHO?

26. WHAT?Refactoring
Infrastructure
Integration
Bug fixing
Spike

27. … and what do you need
to know?

28. WHAT?Refactoring
Infrastructure
Integration
Bug fixing
Spike

29. IntegrationData mapping
Dictionaries
Frequency
Collisions
Event based
vs. scheduled
Failure strategy
… other

30. Sequence diagram

31. WHY?
WHAT? WHO?

32. WHO?
Business Users
Developers
Testers
Data Analysts

33. What is next?

34. Source: http://geek-and-poke.com/

35. Make a list of items!

36. Metrics

40. Keep the items that
improve the situation!

41. ∞ ÷ 2 ≈ ∞

42. Query response time
Current
2s
Response loading on page
Max number of rows
0,5s
5
After Refactoring
40-60% less
20% more
30% less
Compare metrics

43. Should we use User
Stories?

44. IntegrationData mapping
Dictionaries
Frequency
Collisions
Event based
vs. scheduled
Failure strategy
… other

45. Sample

46. Fit it!

47. Fit it!
… make own type of item that reflects your needs
… don’t be afraid to use fields in tool in creative way
… make own template of description (DoR)
… add your metrics & ways to measure
... remember that items have to be independent!

48. Fit it!
… make own type of item that reflects your needs
… don’t be afraid to use fields in tool in creative way
… make own template of description (DoR)
… add your metrics & ways to measure
... remember that items have to be independent!

49. Fit it!
… make own type of item that reflects your needs
… don’t be afraid to use fields in tool in creative way
… make own template of description (DoR)
… add your metrics & ways to measure
... remember that items have to be independent!

50. Fit it!
… make own type of item that reflects your needs
… don’t be afraid to use fields in tool in creative way
… make own template of description (DoR)
… add your metrics & ways to measure
... remember that items have to be independent!

51. Fit it!
… make own type of item that reflects your needs
… don’t be afraid to use fields in tool in creative way
… make own template of description (DoR)
… add your metrics & ways to measure
... remember that items have to be independent!

52. Query response time
Current
2s
Response loading on page
of rows
0,5s
5
After Refactoring
40-60% less
20% more
30% less
Wrap up
WHY?
WHAT? WHO?

53. Remember!

54. Agile is about adapting

55. User Stories
are not the only way you
can write requirements!

56. Try new ways of writing
down requirements

57. questions