Grooming the Backlog: Plan the Work, Work the Plan

Copyright © 2014 QSM Inc. 1 v1.2
© Quantitative Software Management,
Inc.
Grooming the Backlog:
Plan the Work, Work the Plan
Andy Berner
Quantitative Software Management, Inc.

Agenda
• Grooming the backlog: what’s there to plan?
• Five factors to consider when planning to
groom the backlog
• Three metrics and a milestone to measure
the progress of grooming the backlog

Agenda
groom the backlog

Requirements? Agile???
• “We don’t need no stinkin’ requirements”
and other misunderstandings
• In agile methods vs. waterfall:
– Differences in how requirements are
specified: less writing, more talk
– Differences in when requirements are
specified: “just in time” concurrent with
development

Requirements! Agile!!!
• But there is no difference in purpose or
importance: subject matter experts and
users define what’s needed and what
provides value, not the developers.
• And no difference in the fact that it takes
significant time and effort by multiple
people.

What is Grooming the Backlog?
• Getting the requirements in shape for the
developers to turn into working software
– The right requirements
– At the right level of detail
– With the right priorities
– Just in time to be turned into working software
• “Definition of Ready” is as important as
“Definition of Done”

Why is this important?
• For agile projects,
coding productivity
benefits from more time
spent on requirements
• For waterfall projects, the
productivity of coding
was more steady
• Why? We speculate that serious effort spent
on just-in-time requirements avoids
misunderstanding and unproductive rework.

What is there to plan?
• You must plan and budget:
– Time
– Effort
– Resources
– Expectations
• Unless you plan for the work:
– the resources you need to groom the backlog
won’t be there when you need them
– when they are there, they won’t have the right
expectations of what they need to do

Agenda
groom the backlog

Five factors to consider in your plan
• Keep two views of the backlog
• Who does the work?
• When is the work done?
• The work contour
• Plan for revisions

Which of these is not like the others?
• Choose a seat on a flight
• Check flight arrival gate and time
• Plan a trip
• Choose a return flight

• Choose a seat on a flight
• Check flight arrival gate and time
• Plan a trip
• Choose a return flight
This is a major feature (or epic). All
the others are stories that could be
developed within an iteration.

• Cancel a reservation
• Provide passenger information
• Change the return flight
• Purchase extra miles for loyalty account

• Cancel a reservation
• Provide passenger information
• Change the return flight
• Purchase extra miles for loyalty account
Although all are more or less the
same size, this one is not broken out
from the epic, “Plan a trip.”

Two views of the backlog
• Classic view: prioritized list of “developer-
sized bites” with top ones chosen for next
iteration
…
Choose a return flight
Provide passenger information
Check flight arrival
Buy extra miles for loyalty account
Change the return flight
Choose a seat on a flight
Cancel a reservation
…

Two views of the backlog
• Business view provides context: hierarchy
and relationships at various levels of
granularity show what provides value
Steve Rogalski
http://winnipegagilist.bl
ogspot.com/2012/03/h
ow-to-create-user-
story-map.htm

Techniques for the business view
• User Story Maps
– Term introduced by Jeff Patton
– Two dimensional view of the backlog
• Minimal Marketable Features
– Mark Denne and Jane Cleland-Huang
– “Software by Numbers”
– Prioritize and schedule larger scale features and
their dependencies for overall value
• Traditional requirements hierarchy and trace
relationships

Importance of Two Views
• The classic view is needed to determine
what to do in each iteration
– Functionality in “developer-sized bites”
– Top priorities at the start of an iteration are
developed next: just-in-time requirements
– Can reprioritize and decompose the rest for future
iterations
• Business view is needed to determine the
right requirements to provide value
– Must stabilize the top levels relatively early or
there will be requirements churn down the road

Who grooms the backlog?
• From Bob Galen*:
It Takes a Village to ‘Own’ the Backlog
*Bob Galen (Velocity Partners), “A Tester’s Guide to Collaborating with Product Owners”,
Star Canada, 4/2104

Who’s in the village?
• Product Owner: Responsible for the backlog
and making sure it’s groomed, but the
product owner cannot do all the work
• Business Stakeholders
– Business process owners
– User representatives
– Subject matter experts
– Important: generally not full time on the team!

Who’s in the village?
• Other members of the agile team
– Developers: replace written text with
conversations
– Business analyst (on some teams): bridge the
communication gap between business
stakeholders and developers
– QA specialists: assure proper “definition of done”
– Documentation and training specialists

How much do they work?
ProductOwner
Scrum Master
Business Expert(Exec and SME)
Technical Analyst/Designer
Programmer
Quality Assurance
Documentation
SupportStaff

When is the backlog groomed?
Groom backlog
Build out backlog

Groom backlog
Build out backlog
Groom enough of the
backlog to get going

Groom backlog
Build out backlog
Just-in-time backlog grooming
and requirements detail
discussions concurrent with
coding and testing (remember:
two views!)

Groom backlog
Build out backlog
Code/test final
details and prepare
for release

Groom backlog
Build out backlog
Top levels of
business view
of backlog
stable

The work contour
ProductOwner
Scrum Master
Business Expert(Exec and SME)
Technical Analyst/Designer
Programmer
Quality Assurance
Documentation
SupportStaff

Rework was a “four letter word”
CostofRework
Req. Design Const. Deploy

Agile changes the economics!
Req. Design Const. Deploy
CostofRework
No Longer Valid!

“Embrace Change”
• Major change of direction:
– Can be rapid and dramatic
– In effect, start a new project
– But business doesn’t change direction constantly
• Changes to priorities
– Basic sprint management
– Just-in-time development reduces rework

“Embrace Change”
• Changes to which stories are included
– We learn from the reviews at each iteration
– Some stories are added
– Some stories are removed
– Often doesn’t change the overall size
– There is some loss if stories already developed
are removed

Top levels of
business view of
the backlog stable
“Embrace Change”: Not so much!
• Churn—a productivity killer: Lack of focus
and careful thought (especially on high
level) causes lots of “changing of minds”
that requires rework that could have been
avoided.
• Partial Solution: Work on stabilizing the higher
levels of the business view of the backlog
relatively early.

Rework from emergent req/design
• The agile development team has learned to
“use the simplest design possible” and let
the more complex design emerge as
needed.
• This changed the economics of rework,
especially with automated refactoring tools.
• The code that runs for a story in the released
product is not the same as the code that ran
in the iteration where the story came off the
backlog.

Rework from emergent req/design
• The agile development team has learned to
“use the simplest design possible” and let
the more complex design emerge as
needed.
• This changed the economics of rework,
especially with automated refactoring tools.
• The code that runs for a story in the released
product is not the same as the code that ran
in the iteration where the story came off the
backlog.
The same is true for requirements:
• They emerge over time
• You need to go back over earlier
stories as later stories are defined.
• This speeds progress, rather than
hinders it.

Example of emergent rework
• Early stories:
– Customer saves address
– Checkout (uses saved address)
• In a later iteration add a new story:
– Customer can save multiple addresses
• You have to rework the “checkout” story:
– Customer chooses billing address from saved
addresses
– Customer chooses shipping address from saved
addresses

Example of emergent rework
• Early stories:
– Customer saves address
– Checkout uses saved address
• In a later iteration add a new story:
– Customer can save multiple addresses
• You have to rework the “checkout” story:
– Customer chooses billing address from saved
addresses
– Customer chooses shipping address from saved
addresses
This is not a problem, it actually saves
time, but you do need to plan for this
rework and set expectations
• You do not define all the detail of
future stories in advance!
• It will be hard to convince SME’s to
postpone discussion of details.
• Remember “YAGNI” (“You ain’t
gonna need it”)

Agenda
groom the backlog

Purpose of these metrics
• Quick course corrections
– Make sure backlog is groomed just in time for
story development
• Spot potential trouble before it happens
• Replan if needed
• The metrics we will present are not the only
ones you will need. These are focused on
tracking and controlling progress on
grooming the backlog.

Anatomy of a metric
Story Pts Defined
1 2 3 4 5 6 7 8 9 10 11 12
Apr
'14
May Jun Jul Aug Sep Oct Nov Dec Jan
'15
Feb Mar Apr May Jun
0
100
200
300
400
500
StPts
87654321

Anatomy of a metric
Story Pts Defined
1 2 3 4 5 6 7 8 9 10 11 12
Apr
'14
'15
Feb Mar Apr May Jun
0
100
200
300
400
500
StPts
87654321
Actual values
collected so far

Anatomy of a metric
Story Pts Defined
1 2 3 4 5 6 7 8 9 10 11 12
Apr
'14
'15
Feb Mar Apr May Jun
0
100
200
300
400
500
StPts
87654321
Projected values
based on plan
(Note the shape)

Anatomy of a metric
Story Pts Defined
1 2 3 4 5 6 7 8 9 10 11 12
Apr
'14
'15
Feb Mar Apr May Jun
0
100
200
300
400
500
StPts
87654321
Control bounds to
assess variation from
plan: Doing OK

Anatomy of a metric
Story Pts Defined
1 2 3 4 5 6 7 8 9 10 11 12
Apr
'14
'15
Feb Mar Apr May Jun
0
100
200
300
400
500
StPts
87654321
Control bounds to
plan: Watch out!

Anatomy of a metric
Story Pts Defined
1 2 3 4 5 6 7 8 9 10 11 12
Apr
'14
'15
Feb Mar Apr May Jun
0
100
200
300
400
500
StPts
87654321
Control bounds to
plan: Trouble!!

Anatomy of a metric
Story Pts Defined
1 2 3 4 5 6 7 8 9 10 11 12
Apr
'14
'15
Feb Mar Apr May Jun
0
100
200
300
400
500
StPts
87654321
Overall assessment

Three key backlog grooming metrics
Story Point Metrics
Story Pts Defined
1 2 3 4 5 6 7 8 9 10 11 12
'15
Feb Mar Apr May Jun
0
100
200
300
400
500
600
700
StPts
87654321
Cum Eff StPts
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Jul
'14
Aug Sep Oct Nov Dec Jan
'15
Feb Mar Apr May Jun Jul Aug Sep
0
100
200
300
400
500
600
700
StPts
987654321
Story Point Burndown
2 3 4 5 6 7 8 9 10 11 12 13 14 15
Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep
0
200
400
600
800
StPts
98765432
Milestones and Planned Phase Schedules - Agile Test
Data:Current Plan
Phase
StoryWriting
Development/Test
Start Date
6/1/2014
7/13/2014
End Date
6/16/2015
7/14/2015
Start Date
(Months
From
Project
Start*)
0.00
1.42
End Date
(Months
From
Project
Start*)
12.53
13.45
Duration
(Mos.)
12.53
12.03
Data:Actual
Phase
StoryWriting
Development/Test
Start Date
6/1/2014
7/13/2014
End Date
10/31/2014
10/31/2014
Start Date
(Months
From
Project
Start*)
0.00
1.42
End Date
(Months
From
Project
Start*)
5.00
5.00
Duration
(Mos.)
5.00
3.58
Milestones:Current Plan
Milestone
ID
Milestone
Acronym Milestone Date
Months From
Project Start*

Metric 1: Story Points (or Stories) Defined
• Typically measured as a total of story points,
or as a count of stories
– If counting, are they “equal sized”?
• Runs parallel to, but leads, Story Points
(Stories) Developed.
Story Points Developed
0
100
200
300
400
500
600
700
StPts
2
Story Pts Defined
0
100
200
300
400
500
600
700
StPts
2

Metric 1: Story Points (or Stories) Defined
• If Story Points Defined is running “low”, that at
least partially explains why Story Points
Developed is running low.
• If Story Points Defined is running above Story
Points Developed, make sure the stories are
really “getting to ready”
– Also consider “work in progress” limits if you are
using those methods
– You may want a “tight” control bound on the high
side

Metric 2: Story Definition Effort
• Track the effort put into grooming the
backlog and Story Definition in general
• The shape is more “front loaded” than effort
for Story Development
– This accounts for the work on the higher levels of
the user story map.
– If the effort is not high enough early, are the
higher levels of the business views being
discussed properly? Or will there be churn later?
• Include the time of developers who are in
conversations detailing the requirements.

Metric 3: Backlog Remaining
• “Traditional” burndown chart but with plan
and control bounds.
• The “real measure” of where we are
compared to where we want to be!
2 3 4 5 6 7 8 9 10 11 12 13 14 15
Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep
0
200
400
600
800
StPts
98765432

Burndown vs. Story Points Developed
• Why isn’t the Burndown Chart just the Story
Points Developed “upside down”?
– Equivalently, is this the right equation?
• Backlog remaining = Plan – Story Points Developed?
• It isn’t, because the Burndown Chart includes
changes to the backlog
– The equation is:
• Backlog remaining = Plan – Story Points Developed +
Story Points Added – Story Points Removed
• Stories removed may include stories already
defined and developed!

Indication of Requirements Churn
• Too little “progress towards 0” on the
burndown, while Story Points Defined and
Story Points Developed are going up nicely
indicates requirements churn!
Story Pts Defined
0
100
200
300
400
500
600
700
StPts
87654321
Cum Eff StPts
0
100
200
300
400
500
600
700
StPts
987654321
0
200
400
600
800
StPts
98765432

MMF Stabilized Milestone
• Milestone: point in time when we expect
something to be completed
• Add a milestone for “Minimal Marketable
Features Stabilized” (or whatever represents
the upper levels of the business view of the
backlog, e.g. top levels of User Story Map)
– Not too early, not too late: maybe 30-40%
through the project
• Missing that milestone is an early warning
sign of trouble to come.

When metrics are “out of control”
• Control bounds show natural variation. Don’t
expect “exact tracking to plan.”
– Expect metrics to go above and below plan
– If they stay in the “green zone” or occasionally
dip into the “warning” zone, you’re ok
• If you understand why they are in the
warning zone, you may be able to take
some action.
– Expect to see them back green soon

Reforecasting
• When actuals are consistently out of the
“green zone” in the same direction and
milestones are late, it’s time to reforecast.
• Use actuals to forecast to completion
– Different metrics may give different answers
– Weigh multiple metrics
– Include plan changes

Anatomy of a forecast
98653
Original plan and
duration

98653
New forecast is
extended from
actuals—what we
are doing
“trumps” what we
planned

98653
New projected
plan based on
actuals and
higher expected
total

98653
Accept forecast
as the new plan.
Note actuals so
far are now
“according to
plan”

Summary: Track Backlog Grooming
• Story Points Defined (compare to Story Points
Developed)
• Effort (expect front-loading, but still
significant throughout the project)
• Burndown (compare to Story Points
Defined/Developed to look for churn)
• MMF Defined (or equivalent) Milestone
• Watch how actuals compare to plan and
control bounds; reforecast when necessary

Questions?
Visit Us at the QSM Booth in the Expo
and Contact Us
Andy Berner (andy.berner@qsm.com)
info@qsm.com
(800) 424-6755
www.qsm.com

Grooming the Backlog: Plan the Work, Work the Plan

Recommended

Recommended

More Related Content

More from TechWell

More from TechWell (20)

Recently uploaded

Recently uploaded (20)

Grooming the Backlog: Plan the Work, Work the Plan