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

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

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.

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

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

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

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

Story template As a I would like So that

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”

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

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

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

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

Story inputs

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

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

Cone of uncertainty

Story Lifecycle IdeaUnderstoodPrioritisedDesignedDeveloped

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

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

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

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

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

Thank you Brett Maytom