Editors Note: The BPMInstitute is excited to share this article written by Omer Schechter. This article was originally published on Toptal.com.
Product backlogs are a critical component of product development: Comprised of a prioritized list of features that guides a product from its initial vision to its execution and formal release. By converting high-level concepts into working details, the product backlog facilitates the creation of a product. Let’s take a closer look at the key steps and the core elements of a product backlog and how a product manager is responsible for creating, prioritizing, and maintaining it.
Split the Backlog into Two Lists
When creating a backlog, define its scope, whether it applies to the entire company’s product line, a subset of products, or just a single product—this helps you manage the features.
Across multiple projects, I have learned that it is good practice to divide the backlog into two lists; the master backlog and the sprint backlog (known as a sprint backlog because 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 the big picture of all of 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. A product manager decides which items to move from one list to another.
Backlog Sources
Next, it is necessary to identify potential sources for features for a backlog. Examples are user research, customer requests, surveys, and detailed marketing research. If you have relevant findings from another product you work with, they can also contribute as a great source. Here are some additional commonly used sources:
- As the QA team works with the product extensively, they can provide valuable feedback and insight into improvements
- A good source of customer feedback can be an unresolved manufacturing issue or a product issue 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
Backlog sources can vary, the most common are product vision, user research, sales and support, and feedback from the QA team.
Abstain from Blocking Features
A good product manager should own the backlog and act as the gatekeeper who controls what features appear 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, 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. 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.
Prioritizing the Backlog
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 in 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.
- A product backlog funnel: Features should be sorted according to the priority.
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 four 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 allows the company to prioritize backlog items in alignment with its 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 adds initial feature descriptions and raw versions of user stories to 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. While you might strive to define a precise user story as a product leader, make sure to keep the team’s input in mind: in my experience, the user story can be significantly improved by the 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. To push the best stories into the development stage, a product manager needs to be proactive and lead the team.
- 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. The short-term product backlog consists of three types of user stories: raw, ready, and done user stories.
Maintaining the Backlog
Periodically, both backlogs—the master and the sprint—should be revised. When the long-term list becomes overloaded with tasks, review the items at the bottom and decide whether they need to be removed or not. Also, be sure to revise the backlog after composing a release plan. With a revised prioritization, you should move items 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. The sprint backlog is an executable list that includes one or more sprints.
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, the CEO, and/or other stakeholders. The list should not be presented as it is—too many details will overwhelm the audience. Instead, focus on two aspects:
Priority mechanism: Justify the weighted criteria for backlog items with data and give a high-level summary of the criteria. 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
Product backlogs represent a move from strategic thinking to day-to-day tactics for product managers. Developing the skills you need to manage, prioritize, update, and maintain a backlog will allow you to build great products and increase your company’s overall performance.
