Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Practical User Stories Brett Maytom Senior Consultant, Readify VIC.NET - 10 May 2011."— Presentation transcript:

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


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

Similar presentations


Ads by Google