This document provides an introduction to agile requirements and user stories. It discusses key concepts such as the agile manifesto, user roles, personas, and developing user stories using the INVEST criteria. The document also covers acceptance tests and how they are used to determine if a user story is complete. It emphasizes that agile requirements focus on interaction, conversation, and confirmation rather than documentation.

1. Agile Intro
Module 2
Agile Requirements

2. Ere wie ere toekomt ...
2

3. Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
3

4. 12 principes
Our highest priority is to satisfy the customer
Working software is the primary
1 measure of progress. 7 through early and continuous delivery of
valuable software.
Agile processes promote sustainable
Welcome changing requirements, even late in
development. The sponsors, developers,
2 and users should be able to maintain a 8 development. Agile processes harness change
for the customer's competitive advantage.
constant pace indefinitely.
Continuous attention to technical Deliver working software frequently, from a
3 excellence and good design enhances 9 couple of weeks to a couple of months, with a
agility. preference to the shorter timescale.
Simplicity--the art of maximizing the Business people and developers must work
4 amount of work not done--is essential. 10 together daily throughout the project.
The best architectures, requirements, Build projects around motivated individuals.
5 and designs emerge from self-organizing
teams.
11 Give them the environment and support they
need, and trust them to get the job done.
At regular intervals, the team reflects
The most efficient and effective method of
on how to become more effective, then
6 tunes and adjusts its behavior 12 conveying information to and within a
development team is face-to-face conversation.
accordingly.
4

5. Sprint Backlog
TO-DO DOING DONE
User Stories
Case
Acceptance
tests
5

6. Sprint Backlog
TO-DO DOING DONE
User Stories
Case
Acceptance
tests
5

7. User Story
As a trainee
I want to know more about User Stories
Because this is a core concept in Agile, determines
the product, the interaction with the customer and
forms the basis for planning
6

8. Why are requirements so
difficult
7

9. Why are requirements so
difficult
7

10. What is a User Story?
• Written description of the story used for
planning and as a reminder
• Conversations about the story that serve
to flash out the details of the story
• Tests that convey and document details and
that can be used to determine when a
story is complete
8

11. What is a User Story?
• Written description of the story used for
planning and as a reminder
• Conversationsaabout the story that serve
As <User Role>
to flash out wantdetails of the story
I the <something>
So I can achieve <value>
• Tests that convey and document details and
that can be used to determine when a
story is complete
8

12. Develop User Stories
User Role
User Story
9

13. Identify User Roles
Receptionist
Patient
Doctor myHospital Local
doctor
Nurse
supporter of patient
10

14. Group User Roles
Patient Receptionist
supporter of patient
myHospital
Doctor Local doctor
Nurse
11

15. Personas
Patient
12

16. Personas
Oma Jans
Patient 90 jaar
zeer hard-horend
slecht ter been
nog nooit met computer
gewerkt
...
12

17. Personas
Oma Jans
Patient Kees
90 jaar
zeer hard-horend
slecht25 jaar
ter been
nog nooit met computer
voetballer
gewerkt
accountant
... ....
12

18. User Stories
As a <User Role>
I want <something>
So I can achieve <value>
acceptance
tests
13

19. User Stories
As a <User Role>
I want <something>
So I can achieve <value>
acceptance
tests
13

20. Cone of Uncertainty
clear, precise
stories
epics
14

21. Trawling
15

22. Trawling methods
• User interviews
• Questionnaires
• Observation
• Workshops
16

23. INVEST in User Stories
• Independent
• Negotiable
• Valuable to users or customers
• Estimatable
• Small
• Testable
17

24. Independent
A user can pay with
Visa card
A user can pay with
Master card
18

25. Negotiable
• A story is NO contract
19

26. Valuable to the user
All error handling is done
through a set of common
classes
20

27. Valuable to the user
All errors are presented to
the user and logged in a
consistent manner
20

28. Estimatable
21

29. Estimatable
• When are stories not estimatable?
21

30. Estimatable
• When are stories not estimatable?
• developers have insufficient domain
knowledge
21

31. Estimatable
• When are stories not estimatable?
• developers have insufficient domain
knowledge
• developers have insufficient technical
knowledge
21

32. Estimatable
• When are stories not estimatable?
• developers have insufficient domain
knowledge
• developers have insufficient technical
knowledge
• stories are too large
21

33. Small
22

34. Small
Too big: split up
- epic with stories
- research and development
22

35. Testable
De software moet een
goede performance hebben
23

36. Testable
Tom Gilb: Planguage
23

37. Planguage
TAG Performance
Users should not have the
GIST feeling they are “waiting for
the system”
PLAN (100 concurrent users) Reponse time < 2s
MUST (100 concurrent users) Reponse time < 5s
PAST (100 concurrent users) Reponse time > 10s
Automatic test script
METER
“PERFORMANCE”
24

38. Kano model
High
Customer satisfaction
Exciters and
delighters ar
line
/
an ce
rm
rfo
Pe Must-have,
mandatory
Low Fully
Absent Feature presence
implemented
25

39. Kano - model
Must-have, Performance, Exciters and
mandatory linear delighters
unexpected,
hygiene factors more is better not required
features
unique selling
dissatisfiers
point
26

40. User Stories vergeleken
• Use Cases (Jacobsen)
• “traditional” requirements (IEEE 830)
• The system shall ...
27

41. User Stories vergeleken
Title: buy a book
Actor: customer
Use
Precondition: book is
Actor
available
• Use Cases (Jacobsen) Main scenario:
1. customer selects book
• “traditional” requirements basket 830)
2. put in (IEEE
3. pay
• The system shall ...Extensions:title
1a search for
1b search for author
3a book not available, delivered
later
27

42. Sprint Backlog
TO-DO DOING DONE
User Stories
Case
Acceptance
tests
28

43. Sprint Backlog
TO-DO DOING DONE
User Stories
Case
Acceptance
tests
28

44. Sprint Backlog
TO-DO DOING DONE
User Stories
Case
Acceptance
tests
28

45. User Story
As a trainee
I want to practice a bit after all theory
Because practice makes perfect
29

46. Case
30

47. Case
Develop a system to support a bar:
• guests can order themselves
• system suggests combinations
• ordering app connects to back-end
• app knows the menu (food &
drink)
• weekly/monthly offers
30

48. Chaos Cocktail Party
• Write an appealing vision for the system on
a card
• 5 Rounds
• Swap card with someone else
• At STOP, make pairs and reward 7 points
• Add the points on your card
31

49. Instruction
• Assign 1 person as Product Owner
• Model User Roles
• Brainstorm User Stories
• Max. 30 minuten
32

50. Sprint Backlog
TO-DO DOING DONE
User Stories
Case
Acceptance
tests
33

51. Sprint Backlog
TO-DO DOING DONE
User Stories
Case
Acceptance
tests
33

52. Sprint Backlog
TO-DO DOING DONE
User Stories
Case
Acceptance
tests
33

53. User Story
As a trainee
I want to know how to handle acceptance test in
Agile
Because a User Story is not complete without a
test
34

54. Acceptance tests
A user can pay with credit card
35

55. Acceptance tests
Test with Visa, Master and Amex (pass)
Test with Diners Club (fail)
Test with good, bad, missing CVC
numbers
Test with expired cards
Test above card limit
35

56. Excercise
Now add some acceptance tests to your
stories
36

57. Sprint Backlog
TO-DO DOING DONE
User Stories
Case
Acceptance
tests
37

58. Sprint Backlog
TO-DO DOING DONE
User Stories
Case
Acceptance
tests
37

59. Summary
• Agile Requirements
• it’s not about the documentation
• but about interaction
• Card - Conversation - Confirmation
38

60. Retrospective
Start doing
Stop doing
Continue doing
39

61. Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
40

62. 12 principes
Our highest priority is to satisfy the customer
Working software is the primary
1 measure of progress. 7 through early and continuous delivery of
valuable software.
Agile processes promote sustainable
Welcome changing requirements, even late in
development. The sponsors, developers,
2 and users should be able to maintain a 8 development. Agile processes harness change
for the customer's competitive advantage.
constant pace indefinitely.
Continuous attention to technical Deliver working software frequently, from a
3 excellence and good design enhances 9 couple of weeks to a couple of months, with a
agility. preference to the shorter timescale.
Simplicity--the art of maximizing the Business people and developers must work
4 amount of work not done--is essential. 10 together daily throughout the project.
The best architectures, requirements, Build projects around motivated individuals.
5 and designs emerge from self-organizing
teams.
11 Give them the environment and support they
need, and trust them to get the job done.
At regular intervals, the team reflects
The most efficient and effective method of
on how to become more effective, then
6 tunes and adjusts its behavior 12 conveying information to and within a
development team is face-to-face conversation.
accordingly.
41