1. Understanding
User Stories
Rachel Davies
rachel@agilexp.com
My Agile timeline
Board
Programmer Agile director Conference Author
on XP team Coach chair
2000 2003 2009
1

2. A few companies ..
About you ..
Does your team build
software from:
• requirements specs?
• from user stories?
• from something else?
2

3. Embrace Change!
• Agile projects focus on delivering value early
and often
• Scope changes allowed throughout the project
• Agile requires involvement of business
throughout the lifecycle to steer priorities and
explain their needs.
Agile Manifesto
• Shared values and principles
for better ways to develop
software (2001)
• www.agilemanifesto.org
3

4. Individuals and interactions
over processes and tools
Working software
over comprehensive documentation
4

5. Customer collaboration
over contract negotiation
Responding to change
over following a plan
5

6. Key Agile Principles
• The goal of Agile Development is to satisfy the
customer through early and continuous deliveryof
valuable software
• Business people and developers must work
together daily throughout the project
• Changing requirements are welcomed, even
late in development
• Focus on flow of value to help prioritize and plan
Traditional Requirements
• Are conveyed in
documents
• Written in impersonal
language
• Tangled together so it’s
hard to separate out
and prioritize
6

7. What other ways can we use to
understand what software to build?
Try User Stories
• User stories help us explore what the software
needs to do from a user perspective.
• Knowing who the user is and what problems
they are trying to solve helps us develop better
software.
7

8. Questions help find context
Ask questions to uncover the user stories..
• Who will use it?
• What problem are they trying to solve?
• What’s their goal?
• Why is this valuable to them?
Understand this before diving into solution
details
?
Time-boxed by definition
“One thing the customer wants the system to do.
Stories should be estimable at between one to
five ideal programming weeks. Stories should be
testable.”
“Stories need to be of a size that you can build a
few of them in an iteration”
“Stories don't have to represent business value to
the customer team, but they do have to
represent progress. Only the customer team
knows what it will consider progress, so they
have to do the slicing” Kent Beck
8

9. Three Cs to a user story
Card: user goal written on an index card
Conversation: team gets to ask questions
Confirmation: acceptance criteria
Ron Jeffries, Xprogramming.com
Team Planning with User Stories
~ 2000
9

10. As a .. I want .. template
(2001)
Story Example
Find a book by ISBN
As a book buyer,
I want to be able to find a book by
entering the ISBN number
so that I can find a specific book quickly
10

11. Example story card
As an operations engineer,
I want to be able to
reconfigure the timeout of a
specific service request
without needing to restart
the backend service process
from
Kerry Jones, BBC
Notice they are not
As a system”!
Acceptance Criteria
Elaborate user stories with examples to
define acceptance criteria
Focus in on demonstrable aspects that we
can use to confirm story is complete
11

12. But ..
Are these user stories?
• “As a user, I want ..X so I can have X
• “As a developer, I want ..
• “As a system, I want ..
Do these help us understand
• user context?
• business value?
Or are they a waste of time?
12

13. Fred’s user story template
• Doesn’t even print to a
single sheet of A4!
• Passed between BA,
Dev, Tester without
conversation
• Same problems as
traditional requirements
Remember this
13

14. Why User Stories Work
• User stories add conversations to the
development cycle
• These conversations do not mean that
documents are abandoned
• But you try to write down less where
possible because that reduces overhead of
maintaining documents
Stories Change Shape
User stories evolve thru conversation
14

15. Pinning down can kill the idea
Iterate software based on feedback
Beware of Epics
Sometimes a story is too large to be implemented in a single iteration, we
call these Epics.
Such stories will need to be broken down for reliable estimates.
15

16. What about non-functional
requirements?
Any Questions?
Contact info:
Email: rachel@agilexp.com
Twitter: rachelcdavies
Blog: http://agilecoach.typepad.com/
16