Creating A Product Backlog

2

3

 Mike Cohn
 The Product Backlog is the master list of all functionality desired in the product. When a project is
initiated there is no comprehensive, time-consuming effort to write down all foreseeable tasks or
requirements. Typically, a project writes down everything obvious, which is almost always more than
enough for a first sprint. The Product Backlog is then allowed to grow and change as more is learned
about the product and its customers. backlog in Scrum is simply a list of things needed to be done.
As such it is a little different from many other to-do lists.
 Scrum Alliance
 The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of
product backlog Items. These included both functional and non-functional customer requirements, as
well as technical team-generated requirements. While there are multiple inputs to the product
backlog, it is the sole responsibility of the product owner to prioritize the product backlog. During a
Sprint planning meeting, backlog items are moved from the product backlog into a sprint, based on
the product owner's priorities.
 Wikipedia
 The product backlog is a high-level document for the entire project. It contains backlog items: broad
descriptions of all required features, wish-list items, etc. prioritized by business value. It is the "What"
that will be built. It is open and editable by anyone and contains rough estimates of both business
value and development effort. Those estimates help the Product Owner to gauge the timeline and, to
a limited extent, priority. For example, if the "add spell-check" and "add table support" features have
the same business value, the one with the smallest development effort will probably have higher
priority, because the ROI.

Copyright © 2008 Russell Pannone - rpannone@WeBeAgile.com. All rights reserved. 4

User Stories Business Story Points
Priority
Story A 1 5
Story B 2 8
Story C 3 1
Story D 4 8
Story E 5 2
Story F 6 2
Story G 7 2
Story H 8 8
Story I 9 5
Story J 10 1

Copyright © 2008 Russell Pannone – rpannone@WeBeAgile.com. All rights reserved. 5

6

Sometimes You Have to See the Big
Project Life Span System Life Span Picture
to Know How the Pieces
Optional
Fit Best Together

Optional

Optional
Bus
Strategy

Use Cases
Business
Model

System Requirements
Functional
&
Non-Functional

Solution/IT-Services
Copyright © 2008 Russell Pannone. All rights reserved. 7

A Simple Product Backlog Example
The Product Owner/Customer tells us they want an implement for writing,
drawing, or marking that is easy to keep sharp, is comfortable to hold, and when
they want to they can easily make a correction.

We collaborate more with the Product Owner/Customer on their needs or
requirements and define the implement’s features and corresponding
benefit/value, as depicted in the table below. Take notice that we have benefits
that influence the implement’s functionality and constrain its design and final
form.

Features Benefits/Value
Is made of wood Easy to sharpen and smells good
Has a specific diameter Comfortable
Surface to be coated Won’t get splinters
Contains a lead composite filler Creates an impressive line
Has an eraser at the end Makes correcting easy

8

Stories for the Product Backlog
• As an implement user I want an implement that is made
of wood so it is easy to sharpen and smells good when
sharpening
• As an implement user I want an implement that has a
specific diameter so it is comfortable to hold
• As an implement user I want the surface of the
implement to be coated so I won’t get splinters when I
use it
• As an implement user I want the implement to contain a
lead composite filler so I can create an impressive line
• As an implement user I want to have at the end of the
implement an eraser so I can easily make a correction

The Final Product

Russell Pannone (805-910-6481) 10

As a Customer I
want to review my
order so that I can
verify my address
is correct


Four factors to consider when prioritizing
1. Degree of uncertainty - the amount and significance of
learning and new knowledge gained by developing the
product increment
2. The amount of risk removed by developing the product
increment
3. The value of having the product increment
4. The cost of developing the product increment

Story Points: Relative Measure of
the Size of a User Story
 What matters are the Product Backlog
relative values
 The raw values we assign are
unimportant
 A story assigned a two
should be twice as much as a
story that is assigned a one;
it should be two-thirds of a
story that is estimated as
three story points
 Estimating in story points
completely separates the
estimation of effort from the
estimation of duration

 The Product Owner is responsible for creating and
maintaining the Product Backlog
 The Product Backlog is not static it is dynamic; marked by
usually continuous and productive activity or change
 The items or stories that make up the Product Backlog come
from various sources
 Inspection and discussion specific to the Product Roadmap
and Release Planning
 As a result of the stories being identified in the first place
(see How Do I Create User Stories for more information)
 The Product Development and Delivery Team are held
accountable for delivering the stories based on the priority of
the story, the team velocity and meeting the conditions-of-
satisfaction for the value-added


15

Project Execution
Project Inception
(Sprints)
Product
Vision
Sprint Plan

Stories and
Backlog

Review and Adapt Develop

Release Plan
From “Agile Project Management” Jim Highsmith Copyright 2004


Release Sprint Sprint
Planning Planning Review &
Retrospective

Roles
- Product Owner
- Scrum Master - Planning
- Team - Daily Standup
- Sprint Review
- Retrospective

Pivotal Progress
Points Items

17

1. Selecting Stories from the
Product Backlog
2. Identifying the tasks to
realize a selected Story
3. Estimating the hours
required to complete the
task
4. ScrumMaster validates total
estimated work against
total team capacity during a
Sprint (# of people *
productive hours/day * # of
days for the Sprint)

18

1. Selecting identified
tasks to complete
2. Completing them
per the team's
definition of done
3. This cycle repeats
until all Story
points for the
Sprint are earned
and/or Sprint is
complete

19

Creating A Product Backlog

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Creating A Product Backlog

Similar to Creating A Product Backlog (20)

More from Russell Pannone

More from Russell Pannone (20)

Recently uploaded

Recently uploaded (20)

Creating A Product Backlog