The Product Backlog: A Step-by-Step Guide

A product backlog is one of the essential parts of the product development chain, a prioritized list of product features that leads from the company’s and product’s vision through execution to a full release. It is a powerful tool, as it converts a high-level vision into the working details of creating a product. Product backlog management falls to the product manager, who has the key responsibility to create, prioritize, and maintain it. Let’s dive deeper into the step-by-step process and core elements of healthy product backlog creation.

Split the Backlog Into Two Lists

Before creating a backlog, define its scope, whether it should apply to a product line, a group of products, or all of the company’s products—this will help you to manage the features.

I have learned across multiple projects that it is a healthy practice to split the backlog into two lists: long-term master backlog and short-term executable backlog (also called a sprint backlog as it can include one or more sprints). The idea is to focus on the most urgent items in order to develop them promptly while at the same time maintaining a big picture of all the features in the master backlog.

In the beginning, both backlogs start as a high-level list of features. However, a sprint backlog usually is split into epics and user stories for easy execution, while the long-term backlog remains as it is. As a product manager, you decide which items should be moved from one list to the other, and when.

How to Create a Product Backlog

The next step is to identify sources that can suggest potential features for a backlog. The source can be user research, a specific customer request, a survey, or detailed marketing research. If you have relevant findings from another product you work with, they can also contribute as a great source. While these are the most common sources, there are a few others:

• The QA team is an excellent source for backlog items, as they use the product extensively and may have valuable feedback for improvements.
• Customer support feedback. In the case of hardware products, a decent source can be a manufacturing problem or issues reported from the field.
• Reviews of the product’s problems, issues, or bugs can also yield ideas of how to improve it.
• Requests from sales
• R&D initiatives or ideas

Abstain from Blocking Features

A good product manager should own the backlog and act as the gatekeeper who controls what features appear on it and are executed. A backlog is constructed so that the high-priority items appear at the top of the list, and the least important ones are at the bottom. Product managers are supposed to promote the inclusion of items in the backlog rather than blocking them. Blocking should occur only in extreme cases, when a product manager is fully confident that a feature is worthless. Instead of blocking the items, let the prioritizing process do the filtering. It may sound irrational, but you can even go as far as including a feature that possibly won’t be developed for five years—having all potential features in one place is a valuable source.

Handling the Items

A backlog consists of high-level features that have to be developed into epics, or user stories, or simply entered with descriptions so they will appear in the backlog. When including them, make sure you have enough information, but do not overwork the details. Look at this product backlog example if you’re unsure. Be agile: Invest time in composing descriptions only when items approach the development stage. A product manager has to keep a balance between seeing the big picture and not going too deep into the details in order to save time and stay efficient.

How is the Product Backlog Arranged?

Sorting the backlog is the core process of prioritization. It is a highly strategic step that focuses on data rather than a gut feeling. Although prioritization is typically the responsibility of a product manager, it usually needs to be confirmed and approved by senior management. Having a structure in place helps you to defend your prioritization decisions. You need to be able to present the structure, communicate it, and get approval for it.

One key requirement for maintaining a healthy prioritization process is to create well-defined weights and evaluation criteria for the backlog features. Different products require different solutions depending on their nature. In the next section, I introduce practical components that can be used as a toolbox to create different formulas for effective prioritization.

Define Criteria for Prioritization

Define criteria that are significant to your product and use them to grade each backlog feature. These criteria should be included for any product:

• Revenues. This criterion is about how much revenue the feature can potentially bring and is based on feedback from the customer or the sales team. Unless there is already an agreed upon deal, the potential revenue will only be a guesstimate. Despite that, it is still a useful metric for prioritization as it helps the product manager avoid features with potentially low return on investment (ROI).
• Market fit and market uniqueness. Market fit shows whether a given feature is solving an existing problem for the users. Market uniqueness is a measure of how unique this new feature is with respect to your competitors. These two items combined will highlight the most relevant features that have not yet been developed by the competition and thus pose a great opportunity.
• Complexity. This criterion combines estimated launch time and the overall complexity of execution. How many functions is this going to impact? What are the direct and potential hidden costs for each? Aim for the shortest possible delivery time with the maximum value that the feature can bring.

Other criteria for consideration depending on the product:

• Confidence. How confident are you that this is going to be used? This is an important criterion for startups, and also when a company is entering a new market.
• Risk. The higher the risk, the lower the score for this criterion. This criterion is closely related to the Confidence criterion.
• Cost. A high implementation cost gets a low score. It is similar to the Complexity criterion, however, there are cases when high cost implies a short development time.

Grading Method

Before giving grades to each backlog feature, set three to five options (very low, low, medium, high) and briefly describe them. For example, with respect to feature development length, the Complexity criterion would have the following grades:

• Very low. It takes only a few days to implement a feature. (This feature gets the highest grade.)
• Low. Implementation takes less than a full sprint or one to two weeks.
• Medium. Implementation takes one sprint or two weeks.
• High. Implementation takes more than one sprint. (This feature gets the lowest grade.)

Do not give the levels sequential numbers (that is, do not use 0, 1, 2, 3). Instead, use this system:

0 points for Very low grade
1 point for Low grade
3 points for Medium grade
9 points for High grade

When employing this grading method, you will get a clear separation of the features’ sum. This makes a substantial difference when you employ it with 30 or 50 features and don’t want to end up with 15 features having the same score—what you want is a clearly sorted priority list.

Define the Weights

The next important step is to define the weights or factors for the chosen criteria. By default, all criteria contribute equally to the feature grades. However, sometimes, criteria have a significantly different impact, thus a more solid contribution. For simplicity, let’s take a numerical example with two criteria: A and B. If you sum points as described above, each criterion will contribute half of the grade. However, when criterion A is twice as important as criterion B, you should come up with a formula like this:

Overall feature’s score = 0.66 * A + 0.33 * B

There could be many different versions of this formula, depending on the factors’ weight that is converted into the number. The weights always have to add up to one.

The weighting method provides flexibility for prioritization and aligns backlog items with the company’s strategy. For example, if a company is focused on short-term revenues, factors related to revenues will have a higher grade in the weighting scheme than others. This way, the features that are expected to gain revenue will appear at the top of a backlog.

Refinement: Toward User Stories

After the prioritization process is completed, the next step with the sprint backlog is to create user stories. A product manager inserts initial feature descriptions and includes the raw versions of the user stories into the backlog. Now is the time to engage a scrum team to create new user stories to respond to users’ needs. Backlog refinement (or grooming) is certainly a result of teamwork. I enjoy brainstorming with a team by turning user stores into features, as this is when an abstract vision shifts toward actual implementation. As a product leader, you might seek to develop a precise user story—keep this in mind, but stay open to the team’s ideas: In my experience, the user story can be significantly improved by the scrum team’s contributions.

The short-term backlog consists of three types of user stories:

• Raw. These are freshly crystallized stories that are being processed at the refinement stage. A product manager has to be proactive and drive the team in order to push the best stories into the development stage.
• Ready. These are stories that are ready for development. At this stage, a product manager has to be hands-on and support execution by answering questions and removing bottlenecks.
• Done. These are completed stories that are ready for deployment and release.

Maintaining the Backlog

Periodically, both backlogs—the master and the sprint—should be revised. When the long-term list becomes overloaded with tasks, review items at the bottom and decide whether they need to be removed or not. Also, make sure to revise the backlog after composing a release plan. With a refreshed prioritization, items should be moved to the short-term backlog if their priority changes. After features are implemented and released, label them as “done” and archive under the master backlog. You might need them for sprint retrospective and KPI measurement.

How to Communicate a Backlog

Since the backlog is a major product building plan, it is crucial for a product manager to effectively communicate it to the team, CEO, or other stakeholders. Do not present the list as it is—there are too many details, and you will lose the audience’s attention. Instead, focus on two aspects:

• Priority mechanism. Give the high-level presentation of backlog items criteria and weights and justify them with supporting data. This way, you will convince the audience that the backlog you built met all the requirements and is aligned with a company’s vision.
• Features. Present the backlog’s features from top to bottom. The detailed level should be audience dependent, and you might need to explain both the features and their grades.

Powerful Tool

A product backlog is a powerful tool for the product manager, as it represents a move from strategic thinking to day-to-day tactics. The skills you develop as a product leader—to manage, prioritize, update, and maintain the backlog—will serve you well in building great products and improving your company’s overall performance.