creating a product backlog

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 - [email protected]. All rights reserved.

User Stories Business

Priority

Story Points

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


BusStrategy

BusinessModel

System RequirementsFunctional

&Non-Functional

Solution/IT-Services

Sometimes You Have to See the Big Picture

to Know How the PiecesFit Best Together

Project Life Span System Life Span

Use Cases

7Copyright © 2008 Russell Pannone. All rights reserved.

Optional

Optional

Optional

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


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


Russell Pannone (805-910-6481)

The Final Product

10

11

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 increment12Copyright © 2008 Russell Pannone – [email protected]. All rights reserved.

What matters are the 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

13

Story Points: Relative Measure of the Size of a User Story

Product Backlog


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


Project InceptionProject Execution

(Sprints)

Product

Vision

Release Plan

Sprint Plan

DevelopReview and Adapt

Stories and

Backlog

From “Agile Project Management” Jim Highsmith Copyright 2004


17

- Planning

- Daily Standup

- Sprint Review

- Retrospective

Roles

- Product Owner

- Scrum Master

- Team

Pivotal

PointsProgress

Items

Copyright © 2008 Russell Pannone. All rights reserved.

Release

Planning

Sprint

PlanningSprint

Review &

Retrospective


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)


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


creating a product backlog

Technology

wikipediathe product

russell pannone

final product russell

product increment copyright

user story

product backlogrelative

mike cohnthe product

implement user