Creating A Product Backlog

 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

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 Copyright © 2008 Russell Pannone – rpannone@WeBeAgile.com. All rights reserved. 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 Copyright © 2008 Russell Pannone – rpannone@WeBeAgile.com. All rights reserved. 9

The Final Product Russell Pannone (805-910-6481) 10

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

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

 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

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

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

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

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

Creating A Product Backlog

by rpannone on Nov 04, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 34

Statistics

Creating A Product Backlog — Presentation Transcript

http://www.slideshare.net	33
http://translate.googleusercontent.com	1