User Stories Applied


Published on

Published in: Business, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

User Stories Applied

  1. 1. Understanding User Stories Rachel Davies My Agile timeline BoardProgrammer Agile director Conference Authoron XP team Coach chair 2000 2003 2009 1
  2. 2. A few companies .. About you ..Does your team build software from:• requirements specs?• from user stories?• from something else? 2
  3. 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) • 3
  4. 4. Individuals and interactions over processes and tools Working softwareover comprehensive documentation 4
  5. 5. Customer collaboration over contract negotiation Responding to changeover following a plan 5
  6. 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. 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. 8. Questions help find contextAsk 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 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 dont 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 8
  9. 9. Three Cs to a user storyCard: user goal written on an index cardConversation: team gets to ask questionsConfirmation: acceptance criteria Ron Jeffries, Team Planning with User Stories ~ 2000 9
  10. 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. 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, BBCNotice they are notAs 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. 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. 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. 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. 15. Pinning down can kill the idea Iterate software based on feedback Beware of EpicsSometimes 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. 16. What about non-functional requirements? Any Questions?Contact info: Email: Twitter: rachelcdavies Blog: 16