1. Agile Intro
Module 2
Agile Requirements
1

2. Ere wie ere toekomt ...
2

3. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
3

4. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
4

5. User Story
Als een cursist
Wil ik meer weten van User Stories
Omdat dit een kernconcept in Agile is, dat
bepalend is voor de interactie met de klant, en de
basis voor de planning
5

6. Waarom zijn
requirements zo moeilijk?
6

7. Waarom zijn
requirements zo moeilijk?
6

8. Wat is een 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
7

9. Wat is een 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
7

10. Ontwikkel User Stories
User Role
User Story
8

11. Identificeer User Roles
Receptioniste
Patient
Dokter myHospital Huisarts
Verpleegster
begeleider Patient
9

12. Groepeer User Roles
Patient Receptioniste
begeleider Patient
myHospital
Dokter Huisarts
Verpleegster
10

13. Cone of Uncertainty
heldere, preciese
stories
grote lijnen
stories
11

14. Trawling
12

15. Product Owner
• De klant, de PO, zou de User Stories
moeten schrijven/geven
• Wie is een goede PO?
• En wie niet?
13

16. Trawling methoden
• Interviews met gebruikers
• Vragenlijsten
• Observatie
• Workshops
14

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

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

19. Negotiable
• Een story is GEEN contract
17

20. Valuable
All error handling is done
through a set of common
classes
18

21. Valuable
All errors are presented to
the user and logged in a
consistent manner
18

22. Estimatable
19

23. Estimatable
• Wanneer zijn stories NIET estimatable?
19

24. Estimatable
• Wanneer zijn stories NIET estimatable?
• ontwikkelaars hebben onvoldoende
domein kennis
19

25. Estimatable
• Wanneer zijn stories NIET estimatable?
• ontwikkelaars hebben onvoldoende
domein kennis
• ontwikkelaars hebben onvoldoende
technische kennis
19

26. Estimatable
• Wanneer zijn stories NIET estimatable?
• ontwikkelaars hebben onvoldoende
domein kennis
• ontwikkelaars hebben onvoldoende
technische kennis
• stories zijn te groot
19

27. Small
20

28. Small
Te groot: dan splitsen
- epic met stories
- onderzoek en ontwikkeling
20

29. Testable
De software moet een
goede performance hebben
21

30. Testable
Tom Gilb: Planguage
21

31. Planguage
TAG Performance
Gebruikers moeten niet het
GIST gevoel hebben “op het
systeem te wachten”
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”
22

32. Kano model
High
Customer satisfaction
Exciters and
delighters ar
lin e
/
an ce
fo rm
Per Must-have,
mandatory
Low Fully
Absent Feature presence
implemented
23

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

34. User Stories vergeleken
• Use Cases (Jacobsen)
• “traditionele” requirements (IEEE 830)
• The system shall ...
25

35. User Stories vergeleken
Use
Actor
• Use Cases (Jacobsen)
• “traditionele” requirements (IEEE 830)
• The system shall ...
25

36. User Stories vergeleken
Title: koop een boek
Actor: klant
Use
Precondition: boek op
Actor
voorraad
• Use Cases (Jacobsen) scenario:
Main
1. klant selecteert boek
• 2. plaats in winkelwagen
“traditionele” requirements (IEEE 830)
3. betaal
• Extensions:
The system shall1a zoek op titel
...
1b zoek op auteur
3a boek niet op voorraad, wordt
later geleverd
25

37. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
26

38. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
27

39. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
28

40. User Story
Als een cursist
Wil ik na al die theorie wel een beetje oefenen
Omdat oefening kunst baart
29

41. Case
Ontwikkel een applicatie om
thuiszorg uitleen te beheren
• database met hulpmiddelen
• locatie
• sorteer/zoek mogelijkheden
• uitleen gegevens
• iPhone app voor leners
30

42. Chaos Cocktail Party
• Schrijf een aansprekende visie voor de App
op een kaartje
• 5 Rondes
• Wissel kaartje uit met anderen
• Bij STOP, maak tweetallen, verdeel 7
punten over de 2 kaartjes
• Tel de punten op de kaartjes bij elkaar op
31

43. Instructie
• Benoem 1 persoon als Product Owner
• Modelleer User Roles
• Brainstorm User Stories
• Max. 30 minuten
32

44. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
33

45. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
34

46. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
35

47. User Story
Als een cursist
Wil ik weten hoe Agile met acceptatie-tests
omgaat
Omdat een User Story blijkbaar niet af is zonder
acceptatie test
36

48. Acceptatie tests
A user can pay with credit card
37

49. Acceptatie tests
Test met Visa, Master and Amex (pass)
Test met Diners Club (fail)
Test met goede, slechte, ontbrekende
CVC nummers
Test met verlopen cards
Test met bedrag boven card limit
37

50. Wie schrijft de tests?
• The Customer !
• Programmer can help
38

51. Goede/slechte tests
• Goed
• value to the user/customer
• Slecht
• basis programmeer-hygiëne
• datum = 30 februari
39

52. Test gedurende Sprint
VOOR DE SPRINT TIJDENS DE SPRINT
Acceptatie op Eerst test schrijven,
User Story dan pas code
40

53. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
41

54. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
42

55. Samenvatting
• Agile Requirements
• niet de documentatie is belangrijk
• maar de interactie
• Card - Conversation - Confirmation
43

56. Retrospective
Start doing
Stop doing
Continue doing
44

57. 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.
45

58. 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.
46