More Related Content
Similar to Creating A Product Backlog (20)
More from Russell Pannone (20)
Creating A Product Backlog
- 1. Copyright © 2008 Russell Pannone – rpannone@WeBeAgile.com. All rights reserved.
- 2. Copyright © 2008 Russell Pannone – rpannone@WeBeAgile.com. All rights reserved.
2
- 3. Copyright © 2008 Russell Pannone – rpannone@WeBeAgile.com. All rights reserved.
3
- 4. 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
- 5. 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. Copyright © 2008 Russell Pannone – rpannone@WeBeAgile.com. All rights reserved.
6
- 7. 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
- 8. 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
Copyright © 2008 Russell Pannone – rpannone@WeBeAgile.com. All rights reserved.
8
- 9. 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
Copyright © 2008 Russell Pannone – rpannone@WeBeAgile.com. All rights reserved. 9
- 11. As a Customer I
want to review my
order so that I can
verify my address
is correct
Copyright © 2008 Russell Pannone – rpannone@WeBeAgile.com. All rights reserved. 11
- 12. 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
Copyright © 2008 Russell Pannone – rpannone@WeBeAgile.com. All rights reserved. 12
- 13. 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
Copyright © 2008 Russell Pannone – rpannone@WeBeAgile.com. All rights reserved. 13
- 14. 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
Copyright © 2008 Russell Pannone – rpannone@WeBeAgile.com. All rights reserved. 14
- 15. Copyright © 2008 Russell Pannone – rpannone@WeBeAgile.com. All rights reserved.
15
- 16. 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
Copyright © 2008 Russell Pannone – rpannone@WeBeAgile.com. All rights reserved. 16
- 17. Release Sprint Sprint
Planning Planning Review &
Retrospective
Roles
- Product Owner
- Scrum Master - Planning
- Team - Daily Standup
- Sprint Review
- Retrospective
Pivotal Progress
Points Items
Copyright © 2008 Russell Pannone – rpannone@WeBeAgile.com. All rights reserved.
17
- 18. 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)
Copyright © 2008 Russell Pannone – rpannone@WeBeAgile.com. All rights reserved.
18
- 19. 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
Copyright © 2008 Russell Pannone – rpannone@WeBeAgile.com. All rights reserved.
19