Product Backlog FAQs

What is the product backlog?

The product backlog is a prioritised list of work required to create or evolve a product. This includes the product functionality that has to be provided, non-functional requirements, like scalability, robustness, and usability, as well as defects and larger refactoring work.

Unlike a traditional requirements specification, the product backlog is not fixed. Instead, it regularly changes, as new items are discovered and existing ones are adapted based on the user and customer feedback collected, as Figure 1 shows. It is therefore not only a product delivery but also a product discovery tool.

Figure 1: The Product Backlog as a Discovery and Delivery Tool

The product backlog items are prioritised or ordered. The high-priority ones are detailed enough so they can be worked on in the next sprint. Lower priority ones, however, are coarse-grained and act as placeholders. This keeps the backlog concise, and it allows delaying decisions about detailed functionality until more information has become available.

To discover the right functionality, the product backlog has to be directed by a product goal, which states the reason for developing the product. To put it differently, the items in the backlog should help meet the product goal. This avoids the risk that the product backlog becomes a long wish list.

I recommend deriving the product goal from an overarching product strategy via an outcome-based product roadmap, as Figure 2 shows.

Figure 2: Strategy and Roadmap Direct the Backlog

To learn more, read the following articles The Scrum Cycle, Product Goals in Scrum, The Product Backlog as a Learning Tool, Roman’s Product Strategy Model, The Product Roadmap and the Product Backlog.

What does an effective product backlog look like?

An effective product backlog has the following five qualities:

• Goal-oriented: It is directed by a product goal that describes the reason for developing the product and helps decide which items the backlog should contain.
• Emergent: The product backlog changes as new items are discovered, based on user and customer feedback, and existing ones are refined.
• Prioritised: Its items are prioritised or ordered so it’s clear what needs to be worked on next.
• Detailed appropriately: The high-priority items are small enough to be implemented in the next sprint, while lower-priority items are big and coarse-grained. This makes the backlog concise and reduces the initial effort to stock it.
• Estimated: The rough effort required to deliver the product backlog items is known. This is helpful to prioritise by cost-benefit and determine the development progress.

In sum, a product backlog should be directed by a product goal. It should be emergent, prioritised, detailed appropriately, and estimated.

For more advice, read the articles Product Goals in Scrum, The Product Backlog as a Learning Tool, Prioritising the Product Backlog, and How Detailed should the Product Backlog be?

How do I stock the product backlog?

• Choose a clear product goal: Define a specific, measurable outcome for the next two the three months.
• Clear out unrelated items: Remove backlog items that do not support the current goal.
• Identify new items: Determine which features, improvements, or bug fixes are required to meet the goal. Keep the items big and coarse-grained for now.
• Prioritise the backlog items as explained in the FAQ below.
• Refine the high-priority items: Break them into smaller items that can be delivered in a sprint. Ask the development team members to estimate the backlog items.
• Collaborate: Involve the development team members in discovering and capturing the product backlog items.

For more advice, read the article 5 Tips for Stocking the Product Backlog.

How do I prioritise the product backlog?

• Before you start prioritising the backlog, ensure that you know who the product is for and why people will want to use it.
• Make sure that you have chosen a clear product goal that describes the benefit or outcome the product should achieve. Remove items that are not required to meet the goal.
• Prioritise the product backlog initially by risk, considering the user, technology, and business-related risks. This approach accelerates learning, and it avoids failing late when there are fewer options to change course.
• Once you’ve addressed the key risks, prioritise by cost-benefit. This helps you decide which items to provide more comprehensively.
• Take into account dependencies and determine if they require changes to the prioritisation. These include dependencies between items, on team members (skills constraints), and on other teams.
• Use prioritisation techniques that are practical and not too difficult to use, as you will have to regularly reprioritise the product backlog.

You can find more information in the articles Prioritising a Product Backlog When Everything is Important and Prioritising the Product Backlog.

How do I manage and update the product backlog?

The product backlog has to be updated as more information becomes available about what product functionality and user experience design have to be provided. The information is obtained from users and customers on the latest prototype/product increment, for example, by demoing or releasing it.

Generally speaking, you should update the backlog at least once per sprint. This involves taking the following steps:

• Analyse the data/feedback you have collected, for example, by demoing or releasing software to (selected) users.
• Apply the insights gained to the product backlog by removing, adding, and changing items.
• Reprioritise the backlog and decide what to do next.
• Refine the high-priority items so that they are ready to be delivered in the next sprint.

To carry out the work, you might schedule a workshop or adapt it on an as-needed basis. Involve the development team members to leverage their ideas and expertise and ensure that the high-priority backlog items are clear. Managing and updating the product backlog should be a collaborative effort.

To learn more about managing and updating the product backlog, refer to the articles Refining the Product Backlog, The Product Backlog Refinement Steps, and When Should Product Backlog Refinement Take Place?

How do I ensure the backlog is shared and understood by the team?

• Collaborate: Involve the development team members in setting the product goal, discovering new product backlog items, and refining and prioritising existing ones. A great way to achieve this is to run collaborative workshops.
• Value ideas and suggestions: Encourage team members to contribute ideas and challenge assumptions, fostering shared ownership and increasing motivation.
• Co-create: Create the backlog items together with the team members and capture them so that they are easy to understand, for example, in the form of user stories.

For more advice, read the article Empowering Development Teams.

How do I secure stakeholder buy-in?

• Engage: Involve the key stakeholders in setting the product goal.
• Show: Invite them to sprint review meetings and ask for their feedback on the latest prototype/product increment.
• Empathise: Attentively listen to them. Show appreciation for sharing their ideas, requests, and concerns.
• Focus: Don’t say yes to every request. Select ideas and requests based on the product goal: If it helps meet the goal, it should be added to the backlog. Otherwise, consider adding to the product roadmap or discard it.
• Decide: Don’t allow powerful stakeholders to tell you what to do and force you to add their features to the backlog. If you can’t say no, there is likely to be an empowerment issue that you need to address. Speak to your boss and get the Scrum Master/agile coach to support you.

You can find more advice in the articles Making Effective Product Decisions: Tips for Deciding with Stakeholders and Dev Teams, Sprint Review Tips for Product Owners, Empathy in Product Management, Understanding Empowerment in Product Management, and 5 Tips for Saying No to Stakeholders.

How can I reduce an overly large product backlog?

• Limit scope: Use a clear product goal to remove unrelated items.
• Group and aggregate: Use themes and epics to combine related items.
• Eliminate “zombie” items: Delete items that have been in the product backlog for a while and are unlikely to be implemented.
• Split the backlog: Move items into a new backlog, assuming that you unbundle the features into a new product.
• Say no: Decline requests that are not aligned with the current product goal.

For more information, refer to the article Tips for Reducing the Product Backlog Size.

What are common mistakes to avoid with the product backlog?

• Fixed: The backlog is not adapted based on new insights gained from gathering user and customer feedback on prototypes/product increments. In the worst case, it is a traditional requirements specification in disguise.
• Big and unfocused: The backlog lacks a product goal, or the person in charge of the product finds it hard to say no to ideas and requests. This leads to a bloated backlog that may result in a Frankenstein product, a product with a horrible value proposition and a terrible user experience.
• Wrong level of detail: Some backlogs are too detailed, which often correlates with being fixed and inflexible. Others lack detail. Their high-priority items are not ready to be worked on in the next sprint.
• No effective prioritisation: It’s not clear in which order the items should be delivered. This leads to a lack of clarity and focus. It makes it difficult to decide what needs to be done next.
• Not shared: Backlogs that are created and managed without input from the development teams miss out on team knowledge and buy-in.
• Lack of strategic alignment: Without a clear connection to a roadmap or product strategy, the backlog may be guided by the wrong product goals and contain the wrong items. To put it differently, it is virtually impossible to determine the right functionality and write effective user stories if it’s not clear who the users are and why they would want to use the product.
• Neglected: The product backlog is not regularly updated. Existing items aren’t removed or refined, and new items aren’t added. The backlog is therefore in danger of becoming outdated and resulting in a product that is not as valuable as it could and should be.

You can learn more by reading the article Seven Product Backlog Mistakes to Avoid.