Working with the Product Backlog

Agile Product Management with Scrum is the product owner’s guide to creating great products with Scrum. It covers a wide range of agile product management topics including envisioning the product, stocking and grooming the product backlog, planning and tracking the project, working with the team, users and customers, and transitioning into the new role.

This article is an excerpt (Chapter 3 'Working with the Product Backlog') from the book; it introduces the product backlog together with its DEEP qualities. It explains how product backlog grooming works, shares advice on discovering and describing product backlog items, and on structuring the product backlog. ScrumMasters, coaches, team members will also benefit from reading the extract as managing the product backlog is teamwork in Scrum.

Few artifacts in Scrum are as popular as the product backlog. And there is a reason: The product backlog is beautifully simple—a prioritized list of the outstanding work necessary to bring the product to life. Its items can include the exploration of customer needs or various technical options, a description of both functional and nonfunctional requirements, the work necessary to launch the product, and other items as well, such as setting up the environment or remediating defects. The product backlog supersedes traditional requirements artifacts, such as market and product requirements specifications. The product owner is responsible for managing the product backlog; the ScrumMaster, team, and stakeholders contribute to it. Together, they discover the product’s functionality.

This chapter discusses the product backlog along with techniques for effectively grooming it. In addition, we look at some of the more complicated product backlog applications, including how to handle nonfunctional requirements and how to scale a product backlog for large projects.

The deep qualities of the product backlog

The product backlog has four qualities: It is detailed appropriately, estimated, emergent, and prioritized, making it DEEP (I owe the acronym DEEP to Mike Cohn) (. Let’s look at these qualities in more detail.

Detailed Appropriately

The product backlog items are detailed appropriately, as illustrated in Figure 3.1. Higher-priority items are described in more detail than lower-priority ones. “The lower the priority, the less detail, until you can barely make out the backlog item,” write Schwaber and Beedle (2002, 33). Following this guideline keeps the backlog concise and ensures that the items likely to be implemented in the next sprint are workable. As a consequence, requirements are discovered, decomposed, and refined throughout the entire project.

Estimated

The product backlog items are estimated. The estimates are coarse-grained and often expressed in story points or ideal days. Knowing the size of the items helps prioritize them and plan the release. (Detailed task-level estimations are created in the sprint planning meeting; tasks and their estimates are captured in the sprint backlog.)

Emergent

The product backlog has an organic quality. It evolves, and its contents change frequently. New items are discovered and added to the backlog based on customer and user feedback. Existing items are modified, reprioritized, refined, or removed on an ongoing basis.

Prioritized

All items in the product backlog are prioritized. The most important and highest-priority items are implemented first. They can be found at the top of the product backlog, as illustrated in Figure 3.1. Once an item is done, it is removed from the product backlog.

Grooming the product backlog

Like a garden growing wild when left unattended for too long, the product backlog becomes unwieldy when it’s neglected. The backlog needs regular attention and care; it needs to be carefully managed, or groomed. Grooming the product backlog is an ongoing process that comprises the steps listed below. Note that these are not necessarily carried out in the order stated:

• New items are discovered and described, and existing ones are changed or removed as appropriate.
• The product backlog is prioritized. The most important items are now found at the top.
• The high-priority items are prepared for the upcoming sprint planning meeting; they are decomposed and refined.
• The team sizes product backlog items. Adding new items to the product backlog, changing existing ones, and correcting estimates make sizing necessary.

Although the product owner is responsible for making sure that the product backlog is in good shape, grooming is a collaborative process. Items are discovered and described, prioritized, decomposed, and refined by the entire Scrum team—Scrum allocates up to 10% of the team’s availability for grooming activities (Schwaber 2007); stakeholders are involved as appropriate. Requirements are no longer handed off to the team; the team members coauthor them. The product owner, ScrumMaster, and team engage in face-to-face conversations rather than communicating via documents.

Grooming the product backlog collaboratively is fun and effective. It creates a dialogue within the Scrum team and between the team and the stakeholders. It removes the divide between “the business” and “the techies” and eliminates wasteful handoffs. It increases the clarity of the requirements, leverages the Scrum team’s collective knowledge and creativity, and creates buy-in and joint ownership.

Some teams like to do a bit of grooming after their Daily Scrum. Others prefer weekly grooming sessions or a longer grooming workshop toward the end of the sprint. Grooming activities also take place in the sprint review meeting when the Scrum team and the stakeholders discuss the way forward; new backlog items are identified and old ones are removed. Make sure you establish a grooming process so that the activities are carried out reliably, for instance, by starting with weekly grooming workshops. A well-groomed backlog is a prerequisite for a successful sprint planning meeting.

There is a great tool to support product backlog grooming: paper cards. They are cheap and easy to use. They facilitate collaboration; everyone can grab a card and write down an idea. They can also be grouped on the table or wall to check for consistency and completeness.

Cards and electronic product backlog tools, such as spreadsheets, complement each other: Print out existing requirements on paper cards prior to a grooming workshop, and transfer the information on the cards back into the electronic tool afterward. Let’s now look closer at the four steps in the grooming process, beginning with discovering and describing product backlog items.

Discovering and describing items

Discovering and describing product backlog items is an ongoing process. If you are used to creating comprehensive and detailed requirements specifications up front, recognize that Scrum encourages a fundamentally different approach. Requirements are no longer frozen early on but instead are discovered and detailed throughout the entire project. As our understanding of customer needs and how they can best be met improves, existing requirements are likely to change or become redundant, and new requirements will emerge. Product discovery is therefore not limited to the early development stages but covers the entire project in Scrum.

Many product managers transitioning into the product owner role find it challenging not to write down all requirements and not to detail them straightaway—even if they could.

Discovering Items

Discovering product backlog items starts with stocking the product backlog. This is best done as a collaborative effort where the Scrum team and, as appropriate, stakeholders brainstorm the items necessary to bring the product to life, using the product idea, the product vision, or the product road map as a starting point. When stocking the product backlog, avoid the mistake of trying to think of every possible item. Whenever you work on the backlog, focus on the minimum functionality necessary to bring the product to life and strive for simplicity, as discussed in Chapter 2. As the project progresses, more ideas will emerge and the backlog will grow based on customer and user feedback. Starting with an overly long and complex product backlog makes it difficult to create focus and to prioritize items. Use the product idea or vision to guide your efforts.

Focus only on what is critical and do not worry about the rest for now. Resist the temptation to add too much detail too quickly. Items are detailed progressively according to their priority. Low-priority items are large and coarse-grained. They stay like this until their priority changes (either because they are reprioritized or because higher-priority items have been consumed). Nonfunctional requirements that represent product-wide properties are the exception to this rule. These should be detailed early on, as I will explain later in this chapter.

Once the initial product backlog is in place, there are many opportunities to discover new items. These emerge in grooming workshops when the Scrum team prioritizes and decomposes product backlog items, they arise in the sprint review meetings when stakeholders give feedback, and they originate from customer and user comments on released product increments.

Whenever a requirement is entered into the backlog, ensure that the related customer need is properly understood. Ask why a requirement is necessary and how it benefits the customer. Do not make the mistake of blindly copying requirements into the product backlog, as this creates an inconsistent and unmanageable wish list. Treat existing requirements as suspicious and consider them as a liability, not an asset. A requirement simply describes product functionality that was thought to be necessary at some point in time. As markets and technologies change and as the Scrum team gains more knowledge about how customer needs can best be met, requirements also change or become obsolete.

Describing Items

Scrum does not mandate how product backlog items are described, but I prefer to work with user stories (Cohn 2004). As its name suggests, a user story tells a story about a customer or user employing the product. It contains a name, a brief narrative, and acceptance criteria, conditions that must hold true for the story to be complete.

A story can be coarse-grained or detailed; coarse-grained stories are called epics. It’s comparatively easy to write, decompose, and refine user stories. Of course, you are free to use any other technique to describe your requirements. And if you do use stories, you should not feel obligated to describe every single product backlog item as a user story. For instance, usability requirements are often best captured with prototypes or sketches.

Working with a product backlog does not mean that the Scrum team cannot create other helpful artifacts, including a summary of the various user roles, user story sequences to model workflows, diagrams to illustrate business rules, spreadsheets to capture complex calculations, user interface sketches, storyboards, user interface navigation diagrams, and user interface prototypes. These artifacts do not replace the product backlog but instead should elaborate and explain its content. And keep things simple. Only use artifacts that help the Scrum team move closer to a shippable product.

Structuring the Backlog

Product backlogs often benefit from grouping related items into themes. Themes act as placeholders for product functionality; they structure the backlog, aid prioritization, and make it easier to access information. Sample themes for a mobile phone are email, calendar, voice communication, and organizer, for instance. As a rule of thumb, each theme should contain between two and five coarse-grained requirements to start with. This tends to provide enough information to understand what it will take to bring the product to life without over-specifying the backlog contents.

Themes create a hierarchy in the product backlog, which now contains groups in addition to individual items. Additionally, it can be useful to further distinguish between coarse-grained requirements, like epics, and detailed items, like stories, resulting in a product backlog as partially illustrated in Table 3.1.

TABLE 3.1 Sample Product Backlog

The themes in Table 3.1 contain coarse-grained items. Over time, these are decomposed into more detailed items. As the team estimates items, their size is recorded. Note that you can employ the structure in Table 3.1 independently of your product backlog tool, for instance, by appropriately arranging paper cards on a pin board, whiteboard, or the office wall.

This excerpt is from the book, ‘Agile Product Management with Scrum: Creating Products That Customers Love’ by Roman Pichler, published by Pearson/Addison-Wesley Professional, March 2010, ISBN 0321605780, Copyright 2010 Roman Pichler. Visit the publisher page for a complete table of contents.