Welcome! Get ready to learn the basics. Read the whole article or select the topics you’re most interested in below.
- What Is a Product Backlog?
- Why It's Important
- An Example
- Sprint Backlogs Versus Product Backlogs
- Product Backlog Items: What Goes In
- Who Does What? Key Roles
- Further Resources
What Is a Product Backlog?
In essence, 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.
It is common to think of it as a to-do list. Many define it in exactly this way, as a list of things you must do to deliver your product to market.
But this way of thinking masks a very dangerous, and un-Agile, presumption.
In truth, it is not necessarily a to-do list.
Instead, it is much better to think of it as a wish list.
Think of it as a decision-making artifact that helps you estimate, refine, and prioritize everything you might sometime in the future want to complete. The backlog 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).
It is much better to think of a product backlog as a wish list — not a to-do list.
The phrase “might complete” is critical when talking about these items — it is never a given that a particular item will be completed until it is committed, by the team, to a sprint.
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.
The product 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. 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.
Why the Backlog Is Important
The backlog is critical to product success. This can’t be understated. It is the future of your product. It is the present of your product. It is not only the what of your product, but the why, when, and for whom.
Without a well-organized, prioritized backlog, teams must muddle through disorder. They must pause between each development interval and wait for (or make) decisions about what to do next. They risk spending their effort on outdated, obsolete, or unnecessary features with little or no business value.
The backlog is where feedback incubates into valuable features.
Agile methodologies, as models for product development, work so well because they focus on value and deliver this value to customers in increments. So think of the backlog as the innovation engine of your organization. It is where feedback — from customers, strategists, teams, and other stakeholders — incubates into valuable features.
[FREE WHITE PAPER: IS YOUR BACKLOG HINDERING INNOVATION? 6 TIPS]
An Agile Backlog Example
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 for this is that 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.
Product Backlog vs. Sprint Backlog
Content, granularity, and immediacy are three key differences between the product and sprint backlogs.
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 backlog. 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, taken from the product backlog, that the team has committed to delivering within the next sprint’s timeframe, but 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.
Product Backlog Items (PBIs) With Examples
Four main categories of items (called product backlog items or PBIs) fit in the backlog. Two are highly visible to customers — features and bugs. The two others, technical debt and research, are invisible to customers yet can't be ignored.
In an Agile organization, PBIs 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, PBIs 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>.
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>.
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>.
Stakeholders for Product Backlogs
Ultimately, a backlog has many stakeholders, with the customer being most important. The core stakeholders in your organization, however, are product owner, scrum master, and team. Let’s look at each and how they collaborate in the backlog.
Product Owner: Backlog Manager
The product owner maintains the backlog. Their responsibilities include having a vision of what they wish to build and conveying that vision to the team — a task achieved through the backlog. They have a solid understanding of users, the market, competition, and of future trends affecting the product being developed. Importantly, the product owner role has a vision for what is to be built and power to say no to things that do not align with that vision.
- Adds, removes, splits, and prioritizes PBIs through backlog grooming.
- Presents the highest-priority PBIs during the sprint planning meeting and makes sure they are well understood by the team.
- Respects team input and lets them focus during the sprint by not adding or changing committed items during it.
- Approves PBIs once completed by the team.
- Actively engages with teams and product stakeholders.
- Motivates the team with clear, elevating goals.
Scrum Master: Impediment Remover
The scrum master serves as the team's coach, helping team members work together effectively. A good scrum master views the role as a servant-leader to the team, removing impediments to progress, facilitating meetings and discussions, and ensuring the agreed-upon process is being followed.
The scrum master ensures that value is delivered as smoothly and seamlessly as possible. In reality, this means the scrum master must often protect the team from outsiders who may negatively disturb, influence, or control how the team is working.
- Helps teams members work together effectively.
- Identifies and removes impediments to progress.
- Performs what are considered typical project management duties.
- Facilitates meetings, such as sprint planning and sprint retrospective.
Team: Subject Matter Experts and Committers
While the product owner is the key caretaker of the product backlog, the team is responsible to ensure its commitment (as actualized in the sprint backlog) is fulfilled, and that potential issues are identified and addressed before they become problematic.
Generally, the team possesses more authority and accountability for their plan when using product and sprint backlogs as tools for Agile delivery.
For the product backlog, a team member may submit suggestions for backlog items. The reason for this is clear and simple: Many team members, particularly those in QA or others who have perspectives near the product or customer, can bring valuable insight to the product backlog as subject matter experts.
For the sprint backlog, the team selects the amount of work they believe they can accomplish during each sprint. This is called a commitment. It is important that team members have such autonomy; they know best what they are capable of. So, from the top of the product backlog, they select which user stories they can commit to delivering during a sprint. If a backlog item is larger than one sprint, then it should first be broken down into smaller items in the product backlog.
- Selects prioritized user stories from the product backlog to complete during sprint.
- Decides how user stories will be committed to by further breaking them down into tasks and estimating size.
- Converts tasks into working software.
Example: Let’s assume a product backlog with high-priority stories 1, 2, 3, 4 , 5, and 6. The team decides to do stories 1, 2, and 3, but realized that item 3 didn’t have the definition they needed to break it down to tasks. Rather than work on a story that may not be correct, they may decide to commit to story 4, which was similarly sized and defined well.
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.
More on Backlogs
[WHITE PAPER] 6 Tips for a Leaner Product Backlog
[WEBINAR] The Art of Backlog Management