the PowerPoint Presentation Here
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 <persona>
I would like <some feature>
So that <benefit and value>
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
Idea
Understood
Prioritised
Designed
Developed
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 brett.maytom@readify.net
http://brett.maytom.net
