View
1.152
Download
1
Category
Tags:
Preview:
DESCRIPTION
Citation preview
1
UnderstandingUser Stories
Rachel Daviesrachel@agilexp.com
My Agile timeline
20032000
Programmer on XP team
Agile Coach
Author
2009
Boarddirector Conference
chair
2
A few companies ..
About you ..
Does your team buildsoftware from:
• requirements specs?
• from user stories?
• from something else?
3
Embrace Change!
• Agile projects focus on delivering value earlyand often
• Scope changes allowed throughout the project• Agile requires involvement of business
throughout the lifecycle to steer priorities andexplain their needs.
Agile Manifesto
• Shared values and principlesfor better ways to developsoftware (2001)
• www.agilemanifesto.org
4
Individuals and interactions
over processes and tools
Working software
over comprehensive documentation
5
Customer collaboration
over contract negotiation
Responding to change
over following a plan
6
Key Agile Principles
• The goal of Agile Development is to satisfy thecustomer ���through early and continuous delivery ���ofvaluable software
• Business people and developers must worktogether daily throughout the project
• Changing requirements are welcomed, evenlate in development
• Focus on flow of value to help prioritize and plan
Traditional Requirements
• Are conveyed indocuments
• Written in impersonallanguage
• Tangled together so it’shard to separate outand prioritize
7
What other ways can we use tounderstand what software to build?
Try User Stories
• User stories help us explore what the softwareneeds to do from a user perspective.
• Knowing who the user is and what problemsthey are trying to solve helps us develop bettersoftware.
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
?
“One thing the customer wants the system to do.Stories should be estimable at between one tofive ideal programming weeks. Stories should betestable.”“Stories need to be of a size that you can build afew of them in an iteration”“Stories don't have to represent business value tothe customer team, but they do have torepresent progress. Only the customer teamknows what it will consider progress, so theyhave to do the slicing” Kent Beck
Time-boxed by definition
9
Card: user goal written on an index cardConversation: team gets to ask questionsConfirmation: acceptance criteria
Ron Jeffries, Xprogramming.com
Three Cs to a user story
Team Planning with User Stories
~ 2000
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 numberso that I can find a specific book quickly
11
Example story card
As an operations engineer,I want to be able to
reconfigure the timeout of aspecific service request
without needing to restartthe backend service process
fromKerry Jones, BBC
Notice they are not "As a system”!
Acceptance Criteria
Elaborate user stories with examples todefine acceptance criteria
Focus in on demonstrable aspects that wecan use to confirm story is complete
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?
13
Fred’s user story template
• Doesn’t even print to asingle sheet of A4!• Passed between BA,Dev, Tester withoutconversation• Same problems astraditional requirements
Remember this
14
Why User Stories Work
• User stories add conversations to thedevelopment cycle
• These conversations do not mean thatdocuments are abandoned
• But you try to write down less wherepossible because that reduces overhead ofmaintaining documents
Stories Change Shape
User stories evolve thru conversation
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, wecall these Epics.
Such stories will need to be broken down for reliable estimates.
16
What about non-functionalrequirements?
Any Questions?
Contact info:Email: rachel@agilexp.comTwitter: rachelcdaviesBlog: http://agilecoach.typepad.com/
Recommended