Better User Stories:


Have Your Cake and Eat it Too

Hosts: Jeff Sutherland

Joel Riddle

2014ScrumInc.
© 2011 Scrum Inc.
 Who We Are
Scrum Inc. is the Agile leadership company of Dr. Jeff Sutherland, co-creator of
Scrum. We are based at the MIT Cambridge Innovation Center, MA.

CEO Jeff Sutherland helps companies achieve the full benefits of Scrum leading our
comprehensive suite of support services and leadership training:
• Adapting the methodology to an ever-expanding set of industries, processes and
business challenges Training (Scrum Master, Product Owner, Agile Leadership, online
courses, etc.)
• Consulting (linking Scrum and business strategy, scaling Scrum)
• Coaching (hands-on support to Scrum teams)

Chief Content Officer JJ Sutherland and Scrum Master Joel

Riddle maintain the Scrum framework by:
• Capturing and codifying evolving best practices (Scrum Guide)
• Conducting original research on organizational behavior
• Publishing (3 books) and productizing ScrumLab

President Scrum@Hardware Joe Justice leads our hardware consulting practice:

• Worldwide consulting at leading hardware companies
• 700-800% performance improvement in hardware development
• Builds 100 mpg cars in his garage with help from 500 people in 32 countries

We run our company using Scrum as the primary management framework, making
us a living laboratory on the cutting edge of “Enterprise Scrum”

Find  out  more  at  www.scruminc.com.  

2014ScrumInc.
 Agenda

• Discuss what makes a “good” user story, and the

importance of good user stories to Scrum
• Introduce “Stacks” and vertical slicing of
functionality
• Share four tips for writing good independent user
stories
• Product decomposition
• Modular architecture
• User stories, not tasks
• Sanity check often
• Share several different examples of good user
stories in different contexts

2014ScrumInc.
2
 Agile User Stories

Respond  to  
Change

Delight  the   Working  

Customer Agile Manifesto Product

Great  

© 2006-2015 Scrum Inc.

Teams

4
 The Four Horseman of the Apocalypse

Hierarchical  
Thinking

Not  Ready   No Working Layered  

Not  Done Software Stories  

Layered  
Teams

© 2006-2015 Scrum Inc.

Obamacare  had  no  working  stories  at  the  beginning,  in  the  middle,  or  at  the  end!
5
 Symptoms of Bad User Stories

• Excessive effort to figure out what is really meant by the story

Wasted • Additional research needed before work can start/end
Time • Time spent waiting for external dependencies to be cleared

• Back-end infrastructure built with nothing to show customer

• Building something only to discover it is not what the customer
Product
really wanted
Issues • Overly prescriptive stories don’t leave room for innovation by
the team

• Insufficient Definition of Done results in poor product quality

• Sub-components of product developed by different teams don’t
Quality
integrate well
Problems • Over-built features due to lack of clear acceptance criteria
cause code bloat and product liability

2014ScrumInc.
 User Story Readiness Guidelines

Product vision

Product
Backlog ✔ Immediately Can be delivered independently?
actionable Free from external blockage?

✔ N egotiable
Descriptive enough to support
team debate and conversation?

✔ Valuable Delivers customer or business-

visible benefit?

✔ Estimable Clear enough that team can

estimate?

✔ Sized to fit Divided into small enough blocks

to complete within Sprint?

✔ Testable Clear acceptance criteria to know

when it is “good enough?”

Modified from Bill Wake – www.xp123.com

2014ScrumInc.
 User Story Readiness Progression

• All  inputs  accepted  

New Card • Promotion:  Product  Owner  determines  this  story  matches  
Nursery product  goals

• Analysts  decompose  
Elementary • User  experience  experts  research  context  
Increasing  Readiness

School • Business  alignment  needs  identified  

• Promotion:  Matches  release  goals

• Card  details,  acceptance  criteria,  UI  pre-­‐work  (wireframes,  

visual  and  content  prototypes  
Junior High • Legal  &  compliance  issues  reviewed  
• Promotion:  Alignment  with  key  stakeholders  on  features,  
functions,  and  visuals

• Ready  for  sprint  

High School • Candidates  for  Release  Planning/Sprint  Planning  
• Minimal  refinement  expected  on  core  User  Experience

2014ScrumInc.
Not All Backlog Items are User Stories, But All User Stories
Should be “Vertical Slices”

Backlog items include everything Wherever possible, backlog items

the team needs to do in one should deliver complete vertical slices
ordered set of activities of functionality across work layers
Customer   Product    
Features Backlog

Architecture
Testing
GUI
Team   Client
Infrastructure Server
DB  Schema
Research Detailed  Design
Architecture
Risk    
Reduction
Some teams also choose to include process
improvements, bugs and technical debt fixes explicitly as
backlog items

2014ScrumInc.
Breaking the Stack into Independent Stories

All industries have A compelling user story

“stacks” delivers incremental value
across stack layers
E.g. Air travel industry stack Route 1 Route 2 Route 3 Route 4/5

Flight crew, ground crew, security

Aircraft

Food, fuel and baggage handling

Reservation & ticketing systems

Scheduling and routing tools

Runways and terminals

Air traffic control system

2014ScrumInc.
 Not All Features Are Created Equal!
80%  of  
value  
typically  
50 resides  in  
20%  of  
features
Value to Customer

37.5
65%  of  features  provide  little  to  no  value,  
are  rarely  used  and/or  aren’t  actually  
desired  by  the  customer
25

The  rest  are  OK,  

but  not  as  
12.5 important

Features

How  can  you  tell  ahead  of  time  which  features  add  
value  and  which  don’t?

2014ScrumInc.
Better

Delivering Customer Features Incrementally Can

Drive Radically Better Value Delivery

200
180
160
140
120
Value  (%)

100
80
60
40
20

10 20 30 40 50 60 70 80 90 100

Time,  Cost,  Features  (%)

2014ScrumInc.
Four Tips for Writing User Stories as Independent Vertical
Slices

Product

Feature Feature
Maintain and use clear
1 Epic Epic Epic
product decomposition Story
Story
Story

Leverage modular/agile
2
architecture as a foundation

How?
What?
3 Write User Stories, not Tasks
Why?
?!?

Conduct regular vertical slice

4 T
“sanity checks” on all stories T PO
T

2014ScrumInc.
1 Maintain a Clear Product 

Decomposition Hierarchy

2014ScrumInc.
2 Modular/Agile Architecture Needs to 

Support Product Hierarchy!

• Underlying structure is a The 8 modules of the Wikispeed Car

set of largely independent
modules with pre-defined
interfaces  
• Interfaces remain stable,
allowing everything within
the module to change
without impacting other
modules  

• Enables product design to

“emerge” rapidly in
response to inspect and
adapt cycles  
• Also supports re-use of
the same module for
different contexts  

2014ScrumInc.
2 In Software, “Object Oriented” Modularity
Has Been the Norm for a Long Time

• Business components
• Message passing
• Information hiding
• Inheritance
• Polymorphism
• Refactoring

A  type  of  user  needs  an  object  to  do  something  to  generate  value!

2014ScrumInc.
3
Write User Stories, Not Tasks

User  Story Task Task Task

• Focuses  on  WHAT  the  team   • Focuses  on  HOW  the  team  
needs  to  do,  and  WHY  they   will  accomplish  their  work  
need  to  do  it   • Typically  can  be  done  by  one  
• Typically  requires  many  team   or  two  team  members  with  
members  with  different  skills   similar  skill  sets  
to  complete   How? • Often  must  be  completed  
• Can  be  completed   What? sequentially    
independent  of  other  user   • Address  individual  
stories   development  layers  
Why?

Deliver  independent  customer   Do  not  deliver  independent  

visible  value! customer  visible  value!!
Confusing user stories with tasks unnecessarily limits the team’s
ability to innovate, accelerate and try new approaches

2014ScrumInc.
4 Conduct Regular “Sanity Checks”
Despite the best intentions, dependent or task- ?!?
level stories invariably slip through…
Make time as a team to check stories in the T
T PO
backlog regularly T
• E.g. at Sprint Planning or Backlog Refinement

Customer  visible  value  –  does  every  story  

If  no  then  story  probably  
✗ result  in  customer  visible  value?  (customer  
isn’t  independent
not  necessarily  just  an  external  user)
Swarming  –  does  this  story  require  multiple   If  no  then  it  probably  isn’t  
✗ people  to  complete?   a  complete  vertical  slice
External  Dependency  –  Is  this  story  free  
If  no  then  story  probably  
✗ from  dependence  on  other  stories  or  groups  
isn’t  independent
outside  the  team?
Test  Driven  Development  –  Does  this  story  
If  no  then  it  probably  isn’t  
✗ have  clear  and  testable  acceptance  criteria?
a  complete  vertical  slice

2014ScrumInc.
 Example 1: Books and Beyond
• We are building an application for a business that
sells products such as books, movies, music, and
greeting cards. Assume a physical store.
• Your Product Owner has a story: As a customer,
I want to buy a product so that I can enjoy
using it!
• This story is a huge epic. The team needs to work
with the product owner to split it.

2014ScrumInc.
 Where Do We Start?

• What is the first story you would implement?

• Get it ready:
• Immediately actionable
• Negotiable
• Valuable
• Estimable
• Testable
• Any non-functional requirements?

2014ScrumInc.
 Slicing User Story Options Based on Value

• Slicing Requirements for Agile Success

• Ellen Gottesdeiner and Mary Gorman.
Better Software Jul/Aug 2010
• Inspired by:
• Chris Matts and Olav Masson on real
options and feature injection
• Bill Wake and others on story splitting
• Jeff Sutherland and others on ready
requirements
• Dean Leffingwell on lean backlog
• Mike Cohn on minimizing team
handoffs
http://www.ebgconsulting.com/Pubs/Articles/SlicingRequirementsForAgileSuccess_Gottesdiener-Gorman_August2010.pdf

2014ScrumInc.
The Six Slicing Elements of a User Story

2014ScrumInc.
 User Role Options: Types and State

• What are possible user types?

• Individual Buyer
• Corporate Buyer
• Club Member Buyer
• Employee Buyer
• What are possible user roles?
• New
• Existing
• Anonymous
wiki.fluidproject.org
• Archived
• What combination yields the highest immediate value?
• Individual Anonymous Buyer

2014ScrumInc.
 Buyer Action Items

• To identify all possible buyer actions, consider “I

want to buy a product.”
• Ask the Product Owner what typically happens for
an Individual Anonymous Buyer.

iowastatedaily.com

2014ScrumInc.
 Buyer Action Items
• To identify all possible buyer actions, consider “I want to buy a product.”
• Ask the Product Owner what typically happens for an Individual Anonymous
Buyer.
• Verify product cost
• Calculate tax amount
• Calculate total purchase amount
• Apply discount
• Apply wrapping fee
• Arrange for shipping
• Secure payment
• Adjust inventory
• Generate receipt
• Post payment to accounts receivable library.barnard.edu

2014ScrumInc.
What are the Minimum Requirements for the
Next Delivery Cycle?
• Verify product cost
• Calculate tax amount
• Calculate total purchase amount
• Apply discount
• Apply wrapping fee
• Arrange for shipping
• Secure payment
• Adjust inventory
• Generate receipt
• Post payment to accounts receivable

2014ScrumInc.
startitup.co
 Data Option Types and States

• What are product types?

• What are payment types?
• What are receipt types?

2014ScrumInc.
Data Option Types and States: Select for
Value

2014ScrumInc.
 Sliced and Diced Story (so far)

• As an individual anonymous buyer, I want to

buy a new book with cash and receive a cash
receipt.

2014ScrumInc.
Step 4: Business Rule Options

2014ScrumInc.
Exercise Step 5: Interface Type Options

dispatch.com

2014ScrumInc.
Quality Attribute Options

2014ScrumInc.
 Sliced Story
• Immediately Actionable
• Negotiable
• Valuable
• Estimable
• Sized to fit
• Testable

2014ScrumInc.
 Example 2: Software

Autodesk Advance Steel + Revit Software

2014ScrumInc.
 Example 2: Software

Autodesk Advance Steel + Revit Software

As a steel detailer I need to model connections

so that I can determine whether the structural
design will interfere with the work of other
building disciplines.
Acceptance criteria

▪ Appearance of connection will be affected by

current View level of detail
▪ Upon connection creation the user will be able to
see the created geometry at an appropriate level of
detail
▪ Geometry generated in Advance Steel will be
dimensionally identical to geometry generated in
Revit from the same parameter values.

2014ScrumInc.
 Example 2: Software

Autodesk Advance Steel + Revit Software

As a steel detailer, I need to select one or more

steel structural members within Revit so that I
can identify which structural members should be
connected.

Acceptance criteria

▪ Filter selection to structural items including both

steel and concrete
▪ Filter selection to structural items eligible for chosen
connection type
▪ Guided selection of eligible items
▪ Guided selection of items in proper order
▪ API access to eligible items
▪ Identification of connecting ends based on location

2014ScrumInc.
 Example 2: Software

Autodesk Advance Steel + Revit Software

As a steel detailer, I need to select the type of

connection to apply to one or more structural items
so that I can begin making connection decisions
based on an initial design.
Acceptance criteria

▪ Initial availability of < 20 types from Advance Steel

▪ Scalability to ensure eventual availability of
approximately 300 types from Advance Steel
▪ Ability to include type choices from third parties
▪ New type choices will be created outside of Revit

2014ScrumInc.
 Example 2: Software

Autodesk Advance Steel + Revit Software

As a steel detailer, I need to understand the

location, quantity, and diameter of the bolts at
connections represented in Revit, so that I can
further develop the connection detail.
Acceptance criteria
▪ User should be able to measure distances: center of
bolts to side of the plates, between bolts…etc.

2014ScrumInc.
 Example 3: Hardware

Wikispeed Car Suspension Module

User Story: “As a driver, I

want to reduce suspension
vibration so that I enjoy the
ride more”

Key Story Elements

• Adjust shocks to reduce
stiffness of suspension module
• I/O contract between
“suspension” module and
“Chassis” module not impacted
• Therefore, all work can be
completed within one 7-day
sprint
Bolting  pattern,  drive  train  connection  
and  hydraulic  interface  represent  the  
“I/O  contract”

2014ScrumInc.
 Example 4: Services

Context and Background

• New  Scrum  Inc.  class  to  teach  the  application  of  Scrum  
to  both  hardware  and  software  
• Not   sure   of   market   interest,   but   determined   course  
would  be  held  if  it  attracted  at  least  10  students  to  sign  
up  
• Decided  to  market  on  Kickstarter  to  test  the  water  and  
go  from  there

2014ScrumInc.
 Example 4: Services

Industry Stack and Sample User Story Vertical Slice

“New Training” Stack MVP: “Can we get 10

registrants in 60 days?”

No “course delivery” activity needed to

Course Delivery
achieve MVP goals…comes in future stories

Be prepared for inevitable

Sales and Customer Support questions and help people enroll

Main push of MVP…

Marketing
get the word out

Thought through only enough for a

Curriculum provocative description…main course
work comes after “go” decision
Materials and Catering “Proof of concept” and budget-level
Need system capable of
Registration & Payment System
enrolling at least 10 people
Logistics (Venue, Date & Time) Need to least select date and
city for offering (venue nice)

2014ScrumInc.
 Example 5: Dashboard

Context and Background
• Leadership must maintain visibility into org’s progress towards vision/goals.
• To make course adjustments as needed to ensure progress
• Informed decisions require relevant context and metrics
• What are the right/wrong agile metrics to track?
• How do we make sure those metrics are updated with the latest data?
• How do we add and/or tweak them quickly and easily?

2014ScrumInc.
 Example 5: Dashboard

Dashboard Stack and Sample User Story Vertical Slice

User Story: As leadership, we must

“Dashboard” Stack know how net income is burning up for the
year so that we can forecast profits

Set up KPI visualization that clearly

Metric KPI shows profit burn up

Create location in visualization tool

Metrics Dashboard Interface Tool for the KPI and establish data update
cadence

Set up underlying analysis to

Data analysis calculate cumulative monthly net
income data from revenues & costs

Automated Data Aggregation / Automate aggregation of revenue

ERP and cost data into data warehouse

Establish method for collecting

Raw Data Collection revenue and costs data for each
transaction

2014ScrumInc.
 Conclusion
• Writing good independent user stories is vital
• They are not held up by external dependencies
• They can be taken rapidly all the way to Done!
• Getting stories done in the sprint will double team velocity
• It takes both art and science to write stories well
• The tips presented here can help get you started, but
practice makes perfect
• It is as important to recognize a good user story when
you see one

2014ScrumInc.
 Questions?

2014ScrumInc.
 Stay Connected

E-mail
• [email protected]
Twitter, Facebook, and G+
• @Scruminc, #Scrum, #Agile
Our Website  
• www.scruminc.com
• check in for announcements, new content and services, book
releases, and more!  
ScrumLab  
• Scrumlab.scruminc.com
• Articles, videos, papers on all things scrum  
Online Courses  
• Advance your learning with our interactive online courses. Visit
scrumlab to view upcoming topics.  

2014ScrumInc.