Locked lesson.

Upgrade

About this lesson

Requirements are managed in an Agile project using the Project Backlog. This is a prioritized list of the project deliverables.

Exercise files

Download this lesson’s related exercise files.

Product Backlog Exercise.docx
60.8 KB Product Backlog Exercise Solution.docx
59.8 KB

Quick reference

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) create 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.
Login to download
  • 00:04 Hi, this is Ray Sheen.
  • 00:05 It's time to dig into the product backlog.
  • 00:08 This is how project scope is managed.
  • 00:10 I've mentioned the product backlog several times.
  • 00:13 Let me put it in a project management context.
  • 00:16 Think of the product backlog as your statement of work or
  • 00:18 work breakdown structure.
  • 00:20 It is a summary of all of the project deliverables.
  • 00:23 It lists everything you must do on the project.
  • 00:26 It is the closest thing you have to a scope document on an Agile/Scrum project.
  • 00:31 The project backlog is the consolidation of all the Story Cards.
  • 00:35 Each Story Card, which is officially called a Product Backlog Item, or PBI,
  • 00:40 represents a desired project deliverable.
  • 00:43 Have you ever been on a project where the stakeholders gave you a wish list
  • 00:47 of project deliverables and outcomes that went far beyond the time or
  • 00:51 money available for the project?
  • 00:53 That is 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 its own Story Card.
  • 01:01 As the product owner gathers the Story Cards,
  • 01:04 he or she begins to consolidate them into a list.
  • 01:07 In some cases, several stories can be combined.
  • 01:10 In other cases, several stories maybe mutually exclusive.
  • 01:14 When that happens, the product owner must negotiate with the stakeholders to try to
  • 01:18 find an option that meets everyone's needs.
  • 01:21 It's critical that the product owner reach out to all the stakeholders
  • 01:25 to get all the stories and a clear description of the demo criteria or
  • 01:29 the definition of done for each story.
  • 01:31 The Scrum team will deliver the stories, nothing more, nothing less.
  • 01:36 Once the list is complete, the product owner must prioritize
  • 01:40 the list from number one to number last, and there are no ties.
  • 01:44 On a large, complex project, this is the most difficult job that anyone has.
  • 01:49 There are often many stakeholders, and each of them wants to make sure that
  • 01:52 the deliverables that they care most about are near the top of the list.
  • 01:56 Keep in mind, in Agile/Scrum projects, scope is variable,
  • 02:00 each Sprint has a fixed amount of resources and a fixed time.
  • 02:04 The Scrum team works the stories in priority order.
  • 02:08 And if your story is number last, it's very likely that it will not be done.
  • 02:13 To help manage the organization of the list releases are often used.
  • 02:18 On large projects there are normally too many stories to complete in one or
  • 02:22 two Sprints.
  • 02:23 So the product owner will organize the stories into releases.
  • 02:28 Each release will include a number of related stories, so
  • 02:31 that when the stories for that release are completed,
  • 02:34 the Scrum team has created a minimally viable product.
  • 02:37 That means that the stories create a project output that offers a level
  • 02:41 of performance or functionality that is meaningful to the stakeholders.
  • 02:44 Often, the release will be tested and evaluated by stakeholders.
  • 02:48 So as to provide feedback on modifying or refining stories for later Sprints.
  • 02:53 In this way, the project results are incrementally built and
  • 02:57 tested to speed up working out bugs or problems.
  • 03:00 The Product Owner will determine what is in each release.
  • 03:03 However, they often do this with significant input from senior management
  • 03:07 or the business team.
  • 03:08 Since there maybe coordination required with internal or
  • 03:12 external stakeholders to set up the testing and evaluation.
  • 03:15 When creating a release, the Product Owner will often go through the Product Backlog
  • 03:20 and determine for each release which stories are needed.
  • 03:23 Sometimes on a story, the demo criteria maybe modified for
  • 03:27 an early release to provide an initial capability to obtain feedback
  • 03:31 before the final demo criteria is determined.
  • 03:34 As the Product Owner sorts through the Story Cards, they often
  • 03:37 use a categorization approach to determine which stories go into which release.
  • 03:42 My favorite approach is called MoSCoW.
  • 03:44 The M stands for the stories that must be in the release.
  • 03:48 The S stands for those that should be in the release.
  • 03:51 The C stands for those that just could be in the release.
  • 03:55 And the W stands for those that won't be in that release.
  • 03:59 There are a few other categorization approaches, but this is the one I use.
  • 04:03 By the way, the Os were added to make the acronym pronounceable.
  • 04:07 Depending upon the focus of release a very high priority story for
  • 04:12 the overall project maybe categorized as a C or a W for that particular release.
  • 04:18 Following each Sprint, the release plan is reviewed and updated.
  • 04:21 The results of the Sprint demo may indicate the changes needed in
  • 04:25 the priority or categorization of some stories for release.
  • 04:29 The Product Backlog drives all the work of the project.
  • 04:32 It's definitely a living document.
  • 04:34 The product owner must create it and maintain it because it is based upon
  • 04:39 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.

Gift this course