User Stories Applied
•
3 likes•1,711 views
This document discusses user stories and how they can help software development teams understand user needs better than traditional requirements specifications. It provides examples of proper user stories, outlines key principles of writing effective stories, and explains how stories evolve through collaborative conversations between business stakeholders and developers. The document cautions that while documents are not abandoned, less documentation is preferable to reduce overhead and allow stories to change shape based on feedback.
Report
Share
More Related Content
Similar to User Stories Applied
Similar to User Stories Applied (20)
More from IIBA UK Chapter
More from IIBA UK Chapter (20)
Recently uploaded
Recently uploaded (20)
User Stories Applied
- 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