Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Working with the Product Backlog

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.


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.)


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.


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


Coarse-Grained Item

Detailed Item



Create email

As an enterprise user,

I want to be able to state the email subject


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.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Product Backlog is something to be carefully attended

    by Jun Ran,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    When I tried to adopt Scrum in the team, the first challenge is to created a useful Product Backlog.

    So I think this article does help.

  • Three tips for improvements in Product Backlog

    by Marcelo Mrack,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    We are using a Scrum based approach has two years, and due the need to adapt our processes to the PMBOK and MPSbr (in Brazil), three things helped much to improve ours Product Backlogs:

    1. Fine-grained (top level) items in the product backlog registered using an extension of the Feature Driven Design (FDD), in the format AARO (Actor Action Result Object), like "Supervisor (the Actor) print (the Action) a report (the Result) of active users (the Object)."

    2. Detail Product Backlog items using Alistar Cockburn Use Case's approach, remembering that they need be necessarily tested (and eventually automatically).

    3. Use the technique "double of the double" (4h, 8h, 16h, 32h, 64h) to estimate items in the Product Backlog, as encouraged by XProcess (by Andy Carmichael), which is very interesting because it directly incorporates the theory of 80/20 (of available time) for team productivity during the sprint.

  • Re: Three tips for improvements in Product Backlog

    by Michel Löhr,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Question: have you ever implemented Scrum completely as it is, without customizing? If not you are doing ScrumBut(t), please google on it (Ken Schwaber)

  • Grooming the product backlog is always a struggle

    by Stephen Reed,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Now into our 19th sprint (of quite a few more) now working with a multitude of PB stories that have originated from multiple places including the business, user feedback from released sw, PO, the team etc, this article comes at a ideal time for us to refocus on what is most valuable.

    When you are running 2 week sprints grooming the product backlog seems to be just so much more difficult. With time constraints, access to your PO, and trying to clarify / identify which stories are going to be prioritised into the next sprint you are always looking for good ways to eliminate 'waste' in grooming of the PB. This article and the book go a long way to clearly ariculating to the PO and team simple ways to keep focus on what is most valuable to the customer, and what meets the overall vision and goal of the project. Thanks Roman for some clear guidlines to follow.

  • Re: Grooming the product backlog is always a struggle

    by ankit vaid,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Any further tips to break down the Sprint Backlog if the tasks are complex and dleivery is not feasible to be production ready in 3-4 weeks sprint.

    Ankit Vaid

  • Re: Grooming the product backlog is always a struggle

    by Roman Pichler,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Ankit,

    I am not sure I fully understand your question but I'll do my best to give you an answer. If a product backlog item is too big to be delivered in one sprint, we decompose it into several smaller items and deliver them across multiple sprints. Even though product backlog items should be detailed just in time, it may take a few sprints to break down and refine a large epic until the resulting stories are ready to be pulled into the sprint. (I hence talk about progressive decomposition in my book.)

    If the sprint backlog contains a large task then the team should decompose it into smaller tasks as more knowledge about what needs to be done becomes available during the sprint. As a general rule, sprint backlog items should be small enough to allow the team to track their progress in the Daily Scrum. Note that the team should only pull product backlog items into the sprint that can be delivered according to the definition of done. To put it differently: If the team cannot carry out all tasks necessary to transform a user story into a product increment, then it should not commit to the story; the story needs to be broken down before it can be implemented.

    Hope this helps.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p