1. Practical User Stories Brett Maytom Senior Consultant, Readify VIC.NET - 10 May 2011

2. Objective  Introduction  Challenges  Writing stories  INVEST  Story lifecycle

3. What is a story? A concise written description of a piece of functionality that will be valuable to a user (or product owner) of the software.

4. Purpose  Plan work  Prioritise  Track  Build  Test  Report

5. Who needs it  Product owners  Line Managers  Program managers  Project managers  Resource planners  Architects  Designers  Developers  Testers

6. Challenges of weak stories  Unclear  Ambiguous  Different interpretations  Epic (too large)  Dependencies  Importance not understood  Team confusion

7. INVEST (overview)  Independent  Negotiable  Valuable  Estimable  Small  Testable

8. Story template As a I would like So that

9. Persona  Define your personas  Publish a list of personas  Verify story with persona  Story must be defined by the persona  Think as if you had the role of the persona when working on the story  Persona will accept story as “done”

10. Feature  Describe the feature needed  Word it for the product owner and persona  Avoid geek speak  One feature per story  If you cant describe it on one card, then it is probably too big

11. Benefit  Adds additional clarity to feature  Vital for product owners  Why should the product owner spend money to build this feature?  Justify the prioritisation

12. Acceptance Criteria  Given \ When \ Then  If there are too many, it is possible the story should be split into multiple stories  Risks, Issues, Concerns  Identify need for spikes  Identifies uncertainty  Dependencies

13. Who is responsible for the story?  Product owner  Business Analyst (Proxy)

14. Story inputs

15. Independent  Do not overlap  Are not dependant on order  Delivered in any order

16. Negotiable  “Promise to communicate”  Not an explicit contract  Created by product owner and team  Captures the essence of work  Morphs as understanding improves  Does not have to be fully complete

17. Cone of uncertainty

18. Story Lifecycle IdeaUnderstoodPrioritisedDesignedDeveloped

19. Valuable  Valuable to product owner  Technical stories framed in a way that adds value to customer perspective  Split vertical  No Frameworks  Think ROI

20. Estimable  Not exact  Help product owner rank and schedule  Sizing to identify big stories  Spike new and unknown technologies  Team needs to mature over time

21. Small  Small enough to complete in a single iteration  Kept to 2-3 days for done-done  Don’t go to task detail  Big stories indicate lack of detailed understanding

22. Testable  Defines what the product owner will agree to be complete  This is “the contract”  Involve testers early

23. Recommendations  Constantly inspect, adapt and evolve  Clear and explicit  Communicate  Multiple people need to be involved  Constantly work on the stories

24. Thank you Brett Maytom brett.maytom@readify.net http://brett.maytom.net