Locked lesson.
About this lesson
The product backlog is the prioritized list of project deliverables.
Exercise files
Download this lesson’s related exercise files.
Product Backlog.docx61.7 KB Product Backlog - Solution.docx
60.8 KB
Quick reference
Product Backlog
The product backlog is the prioritized list of project deliverables.
When to Use Product Backlog
The product backlog is created at the beginning of the project and reviewed prior to the beginning of the Sprint in order to select the Sprint backlog. The Product backlog is revised at the end of each Sprint based upon the Sprint results and any changes in the business or industry dynamics.
Instructions
- The product backlog is the prioritized list of all project deliverables. As such, it describes the scope of the project.
- Each deliverable is described on a Story Card.
- The Product Owner consolidates all of the Story Cards from all stakeholders and customers into one list. The Product Owner is responsible to ensure the Story Cards are clearly and completely written.
- The Product Owner prioritizes the Story Cards from number one to number last. Once the priority is set by the Product Owner, no one can change it except the Product Owner.
- On large projects, the Story Cards are often organized into a series of Releases. Each Release will be a subset of the deliverables that creates a “Minimally Viable Product.” This means that the deliverables from that Release (combined with any preceding Releases) creates a level of functionality or performance that can be used and tested by stakeholders and customers.
- A Story Card with a very high priority for the project could have a very low priority for a given Release depending upon the focus of the Release.
- Based upon the focus of the Sprint, Story Cards are categorized for that Sprint using MoSCoW (note this is not the same as the priority).
- M – Must have for this Release
- S – Should have for this Release
- C – Could have for this Release
- W – Won’t have for this Release
- The Product Owner plans the Releases, usually with input from senior management and the business functions.
- The Release plan is updated after each Sprint based upon the results of the Sprint Demo.
Hints and Tips
- On a large Agile/Scrum project, the most difficult thing to do is to prioritize the Product Backlog. There are many stakeholders, each of whom considers their deliverables to be among the most important. The Product Owner needs thick skin and good business sense to prioritize the Story Cards – and they should expect to hear some disagreement from stakeholders.
- 00:03 Hi, this is Ray Sheen.
- 00:05 It's to dig in to the Product Backlog.
- 00:07 This how project scope is managed.
- 00:10 I've mentioned the Product Backlog several times.
- 00:14 Let me put in to a project management context.
- 00:17 Think of the Product Backlog as your statement of work or
- 00:20 work breakdown structure.
- 00:22 It is the summary of the project deliverables.
- 00:25 It lists everything that you must do on the project.
- 00:27 It is the closest thing you have to a sculpt statement.
- 00:31 The Product Backlog is the consolidation of all the Story Cards.
- 00:36 Each Story Card, which is officially called a Product Backlog Item,
- 00:39 or a PBI, represents a desired project deliverable.
- 00:43 Have you ever been on a project where the stakeholders gave you a wishlist of
- 00:47 project deliverables and outcomes that were far beyond the time and
- 00:51 money available for the project?
- 00:53 That's a pretty good description of the Product Backlog.
- 00:56 It's a list of everything that everyone wants,
- 00:59 with each item listed on it's own Story Card.
- 01:04 As the Product Owner gathers a Story Cards, he or
- 01:06 she begins to consolidate them into a list.
- 01:08 In some cases, several stories can be combined.
- 01:12 In other cases, several stories maybe mutually exclusive.
- 01:16 When that happens, the Product Owner must negotiate with the stakeholders to
- 01:21 try to find an option that meets everyone's needs.
- 01:24 It's critical that the Product Owner reaches out to all the stakeholders, to
- 01:29 all the story's and a clear description of the demo criteria, or definition of done.
- 01:34 The Scrum team will deliver the stories, nothing more, nothing less.
- 01:39 Once the list is complete, the Product Owner must prioritize the list from Number
- 01:43 1 to Number Last, and there are no ties.
- 01:46 On a large complex project this is the most difficult job that anyone has.
- 01:52 There are often many stakeholders and each of them wants to be sure that
- 01:56 the deliverable that they care most about is near the top of the list.
- 02:00 Keep in mind, an Agile/Scrum project's scope is the variable.
- 02:04 Each Sprint has a fixed amount of resources on a fixed time.
- 02:08 The Scrum Team works the stories in priority order.
- 02:11 And if your story is Number Last, it's very likely that it will not be done.
- 02:17 To help manage the organization of the Backlog List releases are often used.
- 02:22 On a large project there are normally too many stories to complete in one or
- 02:26 two Sprints, so the Product Owner will organize the stories into releases.
- 02:31 Each release will include a number of related stories so
- 02:34 that when the stories for that release are complete,
- 02:37 the Scrum Team has created a Minimally Viable Product.
- 02:40 That means that these stories create a project output that offers a level
- 02:44 of performance or functionality that is meaningful to the stakeholders.
- 02:48 Often the release will be tested and evaluated by stakeholders
- 02:51 to provide feedback on modifying or refining stories for later Sprints.
- 02:56 In this way, project results are incrementally built and
- 02:59 tested to speed up working out bugs and problems.
- 03:03 The Product Owner will determine what is in each release.
- 03:06 However, they often do this with significant input from Senior Management
- 03:10 or the Business Team, since there may be coordination required with internal and
- 03:14 external stakeholders to set up the testing and evaluation.
- 03:18 When creating a release, the Product Owner will often go through the Product Backlog
- 03:21 and determine for each release which stories are needed.
- 03:25 Sometimes the demo criteria for a story may be modified for
- 03:28 an early release to provide an initial capability
- 03:31 to obtain feedback before the final demo criteria is determined.
- 03:36 As the Product Owner sorts through the Story Cards, they often use a categorizing
- 03:40 approach to determine which stories go into which releases.
- 03:44 My favorite approach is called the MoSCoW.
- 03:47 The M stands for stories that must be in the release.
- 03:50 The S stands for those that should be in the release.
- 03:53 C stands for those that could be in the release.
- 03:56 And the W stands for those that won't be in that release.
- 04:00 There are a few other categorizing approaches, but
- 04:03 this is the one that I often use.
- 04:05 By the way, the o's were added to make the acronym pronounceable.
- 04:09 Depending upon the focus of the release, a very high priority story for
- 04:13 the overall project may be categorized as only a C or a W for the release.
- 04:19 Following each Sprint, the release plan is reviewed and updated.
- 04:22 The results of the Sprint demo may indicate the changes needed in
- 04:26 the priority or category of some stories.
- 04:29 The Product Backlog drives all of the work of the project.
- 04:34 It's definitely a living document.
- 04:36 The Product Owner must create it and maintain it because it is based upon
- 04:40 the prioritized Product Backlog that the Scrum Team decides what they will do.
Lesson notes are only available for subscribers.
PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.