Agile Product Backlogs Guide | Master Your Agile Backlog

Learn the basics of Agile product backlogs. Read along or jump to the section that interests you most:

What is a Product Backlog?
An Agile Backlog Example
Agile Product Backlog vs. Sprint Backlog
Product Backlog Items With Examples
How to Create a Product Backlog (Video)

What is a Product Backlog?

A product backlog is a prioritized list of deliverables (such as new features) that should be implemented as part of a project or product development in Agile development. Product backlogs are a decision-making artifact that help you estimate, refine, and prioritize everything you might sometime in the future want to complete. It helps ensure the team is working on the most important and valuable features, fixing the most important bugs, or doing other important work critical to product development. The product backlog, therefore, is tremendously useful in situations when you are unable to do everything being asked (so, most situations), or in contexts when even a small amount of planning will help a lot (so, in most contexts).

Many think of this backlog as a to-do list, and define it in exactly this way, as a list of things you must do to deliver your product to market.

In truth, it is not necessarily a to-do list. Think of it as a wish list.

Think of a product backlog as a wish list — not a to-do list.

Why?

When we think about the backlog as a wish list, we invite flexibility and change. In doing so, we enable true agility and give the organization a power that’s necessary to win in the marketplace today: the power to change its mind.

In this context, the purpose of the backlog can be reduced to three simple goals.

Develop a common ground to align stakeholders and teams, so that teams implement the most valuable user stories.
Provide flexibility to adapt to new needs and realities.
Improve the accuracy of product release forecasts by creating a common denominator across many teams collaborating on one product.

This backlog is often fed by a strategic roadmap, then divided into themes, epics, sprints, and user stories. Most include items that would be completed within the next quarter or fiscal year.

Image Blog Body Scrum Teams Manage Less Huge Backlog Hansoft Priority View 2

[FREE EMAIL WORKSHOP: LEARN ESSENTIAL TIPS FOR BETTER BACKLOGS]

Agile Backlogs Example

Image Article Agile Basics Illustration 1

You might be wondering, what should this decision-making artifact look like?

In honesty, providing a useful example is difficult. That’s because a well-built backlog looks like whatever it needs to in order to help teams build the most valuable product in the time available.

There is little to copy and paste from in that definition!

The reason is that the shape should be informed by the product as well as the processes and needs of the team creating it and committing to it.

In its most basic form, a backlog is for one team and aligned around goals. Those goals are broken down to valuable features and user stories, which in turn are prioritized, estimated, refined, and detailed appropriately.

Below is a product backlog example for a social media game. It’s organized by themes, features, and user stories.

Image Article Agile Basics Body 1 — An example of an Agile backlog organized by themes and features.

Agile Product Backlog vs. Sprint Backlog

Content, granularity, and immediacy are three key differences between the product backlogs and sprint backlogs.

Image Article Agile Basics Illustration 2

In short, the sprint backlog is the short-term plan for the team’s sprint. The product backlog is the long-term plan for the product, where the vision is itemized into concrete deliverable items that make the product more valuable. Many think of the sprint backlog as a subset of the product one. Ideally, this is true; the sprint backlog consists solely of items from the product backlog. In practice, however, a sprint backlog will include other work the team has committed to.

The product backlog is a container for work you think you will do in the future to keep your product competitive. It is the output of the product owner in collaboration with stakeholders (customers, the team, analysts). It will change frequently, with items being added or taken out on a regular basis. It will be larger than the sprint backlog, generally. It will also have items with a mix of granularity; with fewer items broken down below the user story level. It is overseen by the product owner.

The sprint backlog is a container for work the team is committed to doing, either right now as a part of the sprint (typically a one- to four-week period). It is an output of a sprint planning meeting attended by the team. The sprint backlog, ideally, doesn’t change at all for duration of the sprint. It consists of user stories that the team has committed to delivering within the next sprint’s timeframe. But it can also include bugs, refactoring work, and so forth. It is usually more granular, and broken down into tasks, focusing on the technical implementation of a user story. It is the purview of the scrum master and team.

Examples of Product Backlog Items

Four main categories of items (called product backlog items) fit in the product backlog. Two are highly visible to customers — features and bugs. The other two, technical debt and research, are invisible to customers yet can't be ignored.

In an Agile organization, product backlog items are typically written as user stories — though they don’t always need to be. They can also be written as traditional requirements documents, or in a number of other ways.

When written as user stories, product backlog items often take the following form:

As a <stakeholder>, I want <action> so that <benefit>.

1. New Features

Requests for new features originate from a multitude of sources. These include end users, sales, support, product management, and so on. New features can be the most difficult to prioritize as you try to balance the competing needs of:

Keeping existing customers satisfied.
Meeting near-term sales opportunities.
Working toward a longer-term vision of your product.

The product owner should monitor these sources routinely and resolve any conflicting requests. Doing so will help make sure the backlog contains new features that both attract new customers and build loyalty with existing ones.

As a <new feature>, I want <to be understood and prioritized appropriately> so that <I can deliver maximum value to customers and owners>.

2. Technical Debt

Technical debt includes work that needs to be done for the product to stay up to date and be maintainable. Examples of PBIs to address technical debt include upgrading to the latest third-party libraries, making architectural changes to support better scalability, or refactoring the source code to prevent future maintenance issues. When technical debt builds up – whether deliberately or unknowingly — you can risk delaying product releases.

Technical debt is often the result of change regarding:

Direction and scope.
Performance and scalability expectations.
Technology or best practices.

These types of PBIs are often referred to as ”technical debt” because of their similarity to financial debt; you will have to pay interest for them, but in the form of a longer development lifecycle. These tasks should be added to the backlog, and then prioritized along with features and defects, so they can be included in the planning cycle.

As <technical debt>, I want < to be understood and prioritized appropriately> so that <we can maintain and improve the product without delay>.

3. Bugs

Bugs and defects are problems discovered by end users that escaped quality control during development. In a Waterfall process, testing is often the last step of the development lifecycle. It’s quite common to push a release live with a large collection of minor (and sometimes moderate) defects. Bugs tend to cluster and accumulate over time if they aren’t resolved. They are sometimes managed within an issue tracker, but can also be included as a part of the backlog.

As a <bug>, I want <to be understood and prioritized appropriately> so that <problems are addressed early and the product is high quality>.

4. Research

Research is another item the end user won’t recognize as a feature, but can be included in a backlog. Research is instrumental when you know very little about how to implement a new feature or concept, or want to try something new. Either way, circumstances require you set aside time to expand the team’s understanding. The output of these user stories, commonly called “spikes”, is not working code, but knowledge.

As <research>, I want <to be understood and prioritized appropriately> so that <we can lower business risk and innovate>.

How to Create a Product Backlog

Learn how to create a product backlog with this tutorial in Helix Plan.

Bringing It All Together

Proper planning and organization is integral to your success. That’s where backlogs provide guidance. When created and managed correctly, the backlog becomes a tool that helps teams navigate constant change, reach peak productivity, and deliver maximum value to both the business and the customer.