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.
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
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
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
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
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
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
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
Notes de l'éditeur
\n
\n
Toepassing op Requirements\n1\n- ga bij elkaar zitten tijdens release/sprint planning\n- leg uit wat je bedoelt met een requirement\n2\n- voor een sprint van 3 weken kan je veel details wel onthouden, documenteer alleen het noodzakelijke\n- snelle oplevering zorgt ook voor snelle leercurve voor foutief ingeschatte requirements\n3\n- ga bij elkaar zitten ...\n4\n- elke nieuwe sprint kan iets volledig anders zijn dan vooraf gedacht\n
Hoe herken je een extraverte software engineer?\n\nDe business weet niet wat ze wil\nKan het niet uitleggen in termen waar IT iets mee kan\nSoftware engineers zijn verlegen / nerd / houden van puzzelen\n
\n
\n
\n
\n
\n
\n
\n
\n
Mike Cohn, in navolging van Suzanne Robertson, gebruikt de term TRAWLING for user stories. Ernaar vissen. Mooie metafoor. Je vangt niet altijd alles in 1 keer. Moet verschillende netten met verschillende mazen gebruiken om verschillende soorten user stories te vangen.\n
Groot verschil met &#x201C;the system shall&#x201D; is dat daar het systeem beschreven wordt (wat doet het systeem).\nIn use cases en user stories wordt de interactie van de gebruiker met het systeem beschreven.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Twee mogelijke uitvoeringen:\n- voor mij - wat moet ik met deze cursus starten/stoppen/doorgaan\n- voor de deelnemers - wat gaan zij morgen in hun werk doen\nVoorkeur voor de tweede vorm.\n
Toepassing op Requirements\n1\n- ga bij elkaar zitten tijdens release/sprint planning\n- leg uit wat je bedoelt met een requirement\n2\n- voor een sprint van 3 weken kan je veel details wel onthouden, documenteer alleen het noodzakelijke\n- snelle oplevering zorgt ook voor snelle leercurve voor foutief ingeschatte requirements\n3\n- ga bij elkaar zitten ...\n4\n- elke nieuwe sprint kan iets volledig anders zijn dan vooraf gedacht\n