Writing Good User Stories

1. Writing Good User Stories Bob Schommer, CSP, PMP Senior Project Manager Skyline Technologies, Inc.

2. Welcome – Our Objectives for Today • Define the components of a good user story • Discuss the importance of writing stories for unique user roles • Share techniques that will help you to “trawl” for user stories • Provide you with methods for writing good user stories • Have some fun!

3. Agenda • What is a User Story? • Keeping the User in the Story • Going Fishing for Requirements • Acceptance Tests • How to Tell a Good Story

4. The Three C’s • Card • A written description used for • Planning • As a reminder • Conversation • Discussions about the story that flesh out details • Confirmation • Tests that convey and document details • Used to determine when a story is complete A reminder to have a conversation

5. Card • Common format is: • “As a <user role> I would like to <feature> so that <justification>.” • Guideline – not a strict rule • At a minimum include the role and what they want the software to be able to do • “As a pilot I can view my schedule from last month and one month into the future”

6. Conversation • Additional comments about the story • Discussions that have been held • “Andrea said that each trip should include airport, schedule date and actual date” • Unanswered questions • “What should be displayed for short trips?” • Reminders • “Note for UI: Include pop up to show additional details” Remember this is a reminder to have a conversation when the time is right

7. Confirmation • Details already determined in conversations • Acceptance tests can document details uncovered during conversations • “Test with a Captain, First Officer and Flight Attendant” • “Test with a Reserve Pilot” • “Test with a crew member who has been on vacation” • First of two steps for testing • Turned into actual test cases that prove the story has been completed correctly • Write on back of card

8. Why User Stories? • Emphasize verbal communications • Comprehensible by everyone • Right size for planning • Work for iterative development • Encourage deferring detail • Support opportunistic design • Encourage participatory design • Build up tacit knowledge Software requirements is a communication problem

9. Agenda • What is a User Story? • Keeping the User in the Story • Going Fishing for Requirements • Acceptance Tests • How to Tell a Good Story

10. Role Modeling • Stories should be written from perspective of different users of the software • Identify user roles before writing stories • Think beyond the obvious

11. Role Modeling Steps • Brainstorm initial set of user roles • Organize the initial set • Consolidate roles • Refine the roles

12. Role Modeling Guidelines • Focus on identifying roles that can make or break your project • A user role should be one user • Avoid non-human users

13. Other Techniques • Only use these if the additional effort benefits the project • Personas • Imaginary representation of a role • Only write for important roles • Allows team to feel that they know the person • Caution: Requires market and demographic research be done • Extreme Characters • May help uncover new stories • If anything, it may provide some brief entertainment • Examples: • Pope • Drug dealer • Married man who is cheating

14. Agenda • What is a User Story? • Keeping the User in the Story • Going Fishing for Requirements • Acceptance Tests • How to Tell a Good Story

15. Trawl – Don’t “Elicit” or “Capture” • New metaphor for gathering stories • Different sized nets for different sized stories • Not all requirements are worth catching • Some die • You won’t catch everything • You will likely catch some debris • Skill is required

16. Techniques • Story-Writing Workshops • Rapid way to write many stories • Involve all team members • Combine with a low-fidelity prototype • Focus is on screen flow – not actual screens or fields • Ask questions that will help identify new stories: • What will user likely do next? • What mistakes could they make? • What could confuse them? • What additional information might they need? • Throw the prototype away when done writing stories

17. Agenda • What is a User Story? • Keeping the User in the Story • Going Fishing for Requirements • Acceptance Tests • How to Tell a Good Story

18. Acceptance Tests with User Stories • Used to convey details from conversations that have taken place • Criteria that tell when the story is “done” • Should be written by the customer • With support from Testers or Developers • Write before coding begins • Whenever Customer and Developers talk about a story and want to capture details • During iteration planning • When new tests are discovered during or after coding

19. Expanding Tests Before an Iteration • Prior to starting an iteration, the customer should try to write additional tests by asking: • What else do the Developers need to know about this story? • What am I assuming about how this story will be implemented? • Are there circumstances when this story may behave differently? • What can go wrong during the story?

20. Agenda • What is a User Story? • Keeping the User in the Story • Going Fishing for Requirements • Acceptance Tests • How to Tell a Good Story

21. Guidelines for Good User Stories • Start with goal stories for each user role • Identify goals that each user role will have • Decompose from here • “Slice the cake” • Do not split large stories along technical lines • Write stories that will deliver end-to-end functionality • Write closed stories that can be accomplished • Can be finished by achieving a meaningful goal • Balance the six attributes of a good user story (INVEST) • Create constraint story cards • For documenting non-functional requirements • Write “constraint” on card • Do not estimate • Do write acceptance tests when appropriate

22. Guidelines for Good User Stories • Size the story to the horizon • Write small stories for functionality that will be developed within the next few iterations • Goal stories are acceptable for features that are farther in the future • Keep the UI out as long as possible • Causes the solution to interfere with understanding requirements • UI stories will be defined eventually – but not in early iterations • Exception – the UI is important to the success of the product • Not all requirements need to be user stories • Screen shots are appropriate to define the UI • User stories may not be appropriate for some interface specifications • Include the user role in the story • Be as specific as possible. Avoid: “As a user …” • Good template is: “As a <role>, I want <function> so that <business value>”

23. Guidelines for Good User Stories • Write for one user • Avoid plural users • “A Pilot can …” rather than “Pilots can …” • Write in an active voice • A user role should be performing an action • The customer should write • Developers should feel free to suggest stories to the customer • Aids in understanding • Improves prioritization • Do not number them • Adds unneeded overhead • Try writing a short title instead

24. In Closing • References • “User Stories Applied: For Agile Software Development” by Mike Cohn • I highly recommend this book • Evaluation forms • Class certificates