The 1st class of Spring Quarter Agile CP202 slides including: * User Stories * Acceptance Criteria * INVEST Model * Splitting User Stories * Abuse Stories

1. University of Washington
Agile Developer Certificate
Spring Quarter
Advanced Topics in Agile Software
Development
Class #1: User Stories, INVEST Model,
Acceptance Criteria, and Abuse Stories

2. User Stories
Story 14
As a customer I want to check my order
status online so that I can know when to
expect my package

3. User Stories
Story 14
As a customer I want to check my order
status online so that I can know when to
expect my package
A small piece
of business
value that can
be delivered in
an iteration

4. Why User Stories?
• Agile Principle:
– “The most efficient and effective method of conveying
information to and within a development team is
face-to-face conversation”
• User Stories are insufficient to implement
without a conversation between the
customer and delivery team
• Describe vertical slices of functionality
• Words need context to interpret;
requirements are interpreted out of
context in many cases

5. What is a User Story?*
• CARD
– Token representing the requirement. It's used in planning.
Notes are written on it, reflecting priority and cost
• CONVERSATION
– The requirement itself is communicated from customer to
programmers through conversation (The conversation is
largely verbal, but is often supplemented with documents)
• CONFIRMATION
– The confirmation provided by the acceptance test is what
makes possible the simple approach of card and
conversation
– When the conversation about a card gets down to the
details of the acceptance test, the customer and
programmer settle the final details of what needs to be
* “Essential XP: Card, Conversation, Confirmation” – Ron Jeffries
http://www.xprogramming.com/xpmag/EXPCardConversationConfirmation.htm

6. A User Story Template (CARD)
• Describes the value of functionality from a
user’s perspective
User Story Template
As a <<user role>>
I want to <<do something>>
so that <<value/benefit>>
• User Role – a user of the product
• Do Something – feature user needs

7. The INVEST Model
I–N–V–E–S–T
• I =
Independent - dependencies reduce agility
• N =
egotiable - negotiation breeds
N
collaboration
• V =
Valuable - valuable to the Product Owner,
client, customer and user
• E =
Estimable - stories are planning tools
• S =
Sized Appropriately - can be predictably
completed and delivered
• T =
Testable - story (acceptance) tests define
when we are “done”
Source: adapted from Bill Wake, xp123.com (http://xp123.com/xplor/
xp0308/index.shtml)

8. Types of User Stories
• Epic – a user story that has not been
decomposed to meet INVEST model
because it is lower priority
• Theme – a collection of related user
stories

9. Types of User Stories
• Epic – a user story that has not been
decomposed to meet INVEST model
because it is lower priority
• Theme – a collection of related user
stories

10. Interconnections of a User
User Story
• Card
• Conversation
• Confirmation

11. Interconnections of a User
User Story
Value • Card
• Conversation
• Confirmation

12. Interconnections of a User
User Story
Value • Card
• Conversation
• Confirmation
Incremental
Delivery

13. Interconnections of a User
User Story
Value • Card
• Conversation User Perspective
• Confirmation And Focus
Incremental
Delivery

14. Interconnections of a User
User Story
Value • Card
• Conversation User Perspective
• Confirmation And Focus
Incremental
Delivery
The Right
Conversation

15. Interconnections of a User
User Story
Value • Card
• Conversation User Perspective
• Confirmation And Focus
Domain Model, Incremental
System Metaphor, Delivery
Glossary of Terms The Right
Conversation

16. Interconnections of a User
User Story
Value • Card
• Conversation User Perspective
• Confirmation And Focus
Domain Model, Incremental
System Metaphor, Delivery
Glossary of Terms The Right Define Done
Conversation

17. Interconnections of a User
Estimates
User Story
Value • Card
• Conversation User Perspective
• Confirmation And Focus
Domain Model, Incremental
System Metaphor, Delivery
Glossary of Terms The Right Define Done
Conversation

18. Exercise: User Story Writing
Write User Stories for the Jitter
web application.
ID 8.5

19. Acceptance Tests
• Tell us whether the system does what the
customer expects
• Enable Developers to know they’ve
satisfied requirements
• Helps us build the “right” software
• Are also called customer tests or
functional tests
• Can be automated so these can be
verified by anyone at any time
* Adapted from “A Metric Leading to Agility” – Ron Jeffries
http://www.xprogramming.com/xpmag/jatRtsMetric.htm

20. Confirmation Through
Acceptance Criteria
• Product Owner makes first pass at Acceptance
Criteria before Sprint Planning Meeting
• During Sprint Planning, Acceptance Criteria are
discussed
• Final Acceptance Criteria for each User Story is a
negotiation between Delivery Team and Product
Owner
• Should be short, easy to understand statements
Acceptance Criteria
Story 14
•View status as “waiting for
As a customer, I want to check my pickup”, “en route” or
order status online so that I can know “delivered”
when to expect my package •Date of each step in route
•Estimated time of delivery

21. Comparing Acceptance Criteria
to Definition of Done
Definition of Done: Helps us Acceptance Criteria: Helps us
build the thing right build the right thing
Acceptance Criteria
•View status as “waiting for
pickup”, “en route” or
“delivered”
•Date of each step in route
•Estimated time of delivery

22. User Story “Smells”
• Split along process lines
– Design, code, test,
document
• Split across architecture
lines
– Database, Business Tier, UI
• Split along procedural
lines
– Do this, then this, and
finally this

23. *Requirement to User Story – A Case Study
• Our starting requirement:
Story 1
Anyone can register by
paying immediately with
PayPal
* Modified from original article by J.R. Rainsberger - http://www.jbrains.info/weblog/browse/9

24. *Requirement to User Story – A Case Study
• Maybe break it along process lines?:
Story 1.1 Story 1.2
Design: Anyone can Code: Anyone can register
register by paying by paying immediately
immediately with PayPal with PayPal
Story 1.3 Story 1.4
Unit Test: Anyone can Functional Test: Anyone
register by paying can register by paying
immediately with PayPal immediately with PayPal
* Modified from original article by J.R. Rainsberger - http://www.jbrains.info/weblog/browse/9

25. *Requirement to User Story – A Case Study
• Maybe break it along architecture
lines?: 1.1
Story Story 1.2
UI: Anyone can register by Business Logic: Anyone
paying immediately with can register by paying
PayPal immediately with PayPal
Story 1.3 Story 1.4
Database: Anyone can QA: Anyone can register
register by paying by paying immediately
immediately with PayPal with PayPal
* Modified from original article by J.R. Rainsberger - http://www.jbrains.info/weblog/browse/9

26. *Requirement to User Story – A Case Study
• Maybe break it along procedural lines?:
Story 1.1 Story 1.2
Collect registration Integrate with PayPal
information
Story 1.3 Story 1.4
Email registrant after Email organizer after
payment payment
* Modified from original article by J.R. Rainsberger - http://www.jbrains.info/weblog/browse/9

27. *Requirement to User Story – A Case Study
• Aha, self-contained increments of
value…
Story 1.1 Story 1.2
As a Registrant I want to As an Organizer I want to
register with my email so collect more information
that I can be notified from Registrant so that I
electronically can contact them later
Story 1.3 Story 1.4
As a Registrant I want to As an Organizer I want to
be notified of my be notified of a
processed registration so registration so that I can
that I know it is complete fulfill it
* Modified from original article by J.R. Rainsberger - http://www.jbrains.info/weblog/browse/9

28. More Guidelines for Splitting
Stories
• Data boundaries
• Operational boundaries
• Exceptions
• Error handling
• Removing cross-cutting concerns
• Priority

29. Avoid splitting stories too
• Don’t split stories too soon
– Results in huge inventory on Product Backlog
(waste)
– Inertia sets in and clogs system
– Many details will likely be thrown out,
resulting in “sunk costs”
• Progressively elaborate stories based on
– Priority
– Risk
• Effectively splitting stories is a joint effort
– Product Owner, Stakeholders

30. * Abuse User Stories
Implement Security
for User Information
* From “User Stories Applied” presented by Mike Cohn Agile 2006
21

31. * Abuse User Stories
Implement Security As a Malicious Hacker I
for User Information want to steal credit card
information so that I can
make fraudulent charges
* From “User Stories Applied” presented by Mike Cohn Agile 2006
21

32. Abuse Story Workshop
• Agenda (30-60 minute workshop
typically)
– Goal: Generate and Prioritize Abuse
Stories
• Brainstorm Potential Abusers of Application or
Identify Specific Abuser to Use During Session
• Work in Pairs to Generate Abuse Stories; Each
Pair takes on Single Abuser Persona at a Time
• Share Generated Abuse Stories and Prioritize
as Group