Building a Better Backlog - Collab · Building a Better Backlog Strategies for long-term success in...

Angela Druckman

Certified Scrum Trainer

[email protected]

Building a Better Backlog

Strategies for long-term success in Agile

development

mailto:[email protected]

2 Copyright © 2010 CollabNet, Inc. Portions used with permission. All Rights Reserved.

2

Overview

•What is a Product Backlog?

•Writing Product Backlog Items

•User Stories – an Overview

•Grooming the Product Backlog

•Adding Detail

•Estimating Product Backlog Items

•A brief introduction to relative estimation

•Business Value

•Refining Prioritization

•“Granularizing” the Product Backlog

•Product Backlog as Living Artifact


3

What is a Product Backlog?

A prioritized list of physical and intellectual property a Product Owner

is asking for. This could be:

•New features

•Enhancements to existing features

•Prototypes

•Documentation

•Bug fixes

•Training

•Note – a list of the above items is not a Product Backlog until it is

prioritized. Until then, it is simply a “wish list”

“If it’s not on the Product Backlog, it doesn’t exist.” --Jeff Sutherland


4

How to Write Product Backlog Items

A simple statement of what is desired:

•“Provide user documentation for the Accounts Receivable module”

Or a description of actions to take place

•“A customer service representative can log notes from a customer call.”

Many people find the user story format a convenient one for creating

Product Backlog items. One popular format for creating user stories is:

•“As a <type of user> I want to <take some action> so I can <achieve

some result>.

For example:

“As a Customer Service manager, I want to know average queue wait

time so I can provide adequate call center staffing.”


5

What Are the Benefits of User Stories?

•They allow the Product Owner to create

requirements that are implementation-

independent

•They allow requirements to be written from the

perspective of different kinds of users

•They get people to stop talking about the

system and start talking about how people will

user the system

•They are a “promise for a future conversation”

•They can be linked to more extensive

documentation later if desired

•They can be written by both technical and non-

technical people


6

What are the Characteristic of a Good User Story?

I – independent

N – negotiable

V – valuable

E – estimate-able

S – small

T – testable

Good user stories are about the “what” not the “how”


7

Where do User Stories Come From?

Product Owners work with stakeholders to define and write the user

stories. This can be through:

•Individual meetings with stakeholders

•The Product Owner’s team, which may be comprised of requirements

experts like business analysts, requirements analysts, etc

•The Scrum team

•Story Time meetings

Anyone can add items to the Product Backlog but the

Product Owner alone determines the final priority


8

Holding a Successful Story Time session

Most teams (especially early in a project) benefit from

regular Story Time sessions

The goal of a Story Time session is to leave the meeting

with a better product backlog than you arrived with. Story

Time sessions can be used to:

•Write user stories (you can even use this meeting to

create the backlog for the first time)

•Improve the quality of user stories

•Breaking down epics

•Size stories

•Add acceptance criteria to stories

•See and discuss what is coming up for future sprints


9

How Much Detail Should the Product Backlog Have?

Sample Product Backlog 1. ______________

2. ______________

3. ______________

4. ______________

.

.

.

18. _____________

19. _____________

20. _____________

.

.

.

89. _____________

90. _____________

91. _____________

.

.

.

100. ____________


10

Adding Acceptance Criteria

Acceptance criteria:

•Form the “boundaries” of the story (what

is/ is not in scope)

•Are negotiable

•Help us know when a story is complete

• Come from the dialog between the

team and Product Owner in Story Time

and Planning meetings

•Require the ability to ask good

questions


11

Estimating Product Backlog Items

•Teams use a variety of methods to estimate

stories:

–Hours

–Ideal days

–T-shirt sizes (XS, S, M, L, XL, XXXL aka “epic”)

–Fibonacci series style (i.e. – 1,2,3,5,8,13,21…)

•Teams’ estimates of user stories are often

converted into story points, a scale unique to each

team

•The average number of story points delivered by a

given team each sprint is called the team’s velocity

Teams that use T-shirt or Fibonacci scales are using a concept called relative estimation.


12

Why Relative Estimation Works

•Humans are terrible at absolute estimation but

quite good at relative estimation

•It is generally faster

•It gets a team thinking (and talking) as a group,

rather than as individuals

•It encourages spending analysis time appropriately

•It is cost-effective

Remember: estimation is a means to an end. The ultimate goal is an achievable sprint commitment


13

Compare Absolute versus Relative Estimation

Estimate the

weight of the

following animals

in kilograms vs

Rank the animals

below from lightest

to heaviest

• Tiger

• Rabbit

• Squirrel

• Elephant

• Impala


14

Relative Estimation - continued

Some questions you may have asked yourself

in the last exercise:

•Do I have a sense of what the lightest

creature is?

•How about the heaviest?

•Do I know what an impala is? Or do I know

someone who does? (ie – expert knowledge)

•Of the remaining animals, how do they

compare with one another?

Relative estimation is a cost-effective way for teams to

make a sprint commitment with confidence


15

Determining Business Value

Adding a business value metric to your user stories can give the

Product Owner additional information to assist with prioritizing the

backlog. Business value is a organization-specific metric and may

include:

•Return on Investment

•Cost savings

•Labor reduction

•Growth opportunities

•First-to-market

•Opportunity costs

•Cost of not doing


16

Use Estimates and Business Value to Prioritize

For example:

User Story Story Size Estimate

(xs, s, m, l, xl)

Business Value

(1 – 20)

User Story #1 Large 10

User Story #2 Large 16

User Story #3 Small 16

User Story #4

Medium 12

Knowing the value of a backlog item and the effort it will take

to deliver helps the Product Owner make good choices


17

Granularizing the Product Backlog

Product Backlogs can grow quite large. It is therefore useful to granularize or

“chunk” the backlog to help the team understand the Product Owner’s long

term vision. Some chunking ideas are:

Product Backlog A

September Release

PBI #1

PBI #2

PBI #n

December Release

PBI #1

PBI #2

PBI #n

March Release

PBI #1

PBI #2

PBI #n

Product Backlog B

Financial Accounting

PBI #1

PBI #2

PBI #n

Materials Management

PBI #1

PBI #2

PBI #n

Production Planning

PBI #1

PBI #2

PBI #n

Product Backlog C

Front Burner

PBI #1

PBI #2

PBI #n

Back Burner

PBI #1

PBI #2

PBI #n

Freezer

PBI #1

PBI #2

PBI #n


18

The Product Backlog is a Living Artifact!

Product Backlogs require continuous attention

and grooming to:

•Refine backlog items

•Add new items

•Remove outdated items

Be realistic about how much time this will take –

being a Product Owner is a full time job!

Thank You!

Building a Better Backlog - Collab · Building a Better Backlog Strategies for long-term success in...

Documents

Transcript of Building a Better Backlog - Collab · Building a Better Backlog Strategies for long-term success in...