The product backlog is a simple yet powerful tool to capture tactical product decisions and direct the work of the development team. To take full advantage of it, it’s important to set up the initial backlog in the right way. This article offers five practical tips to successfully stock the product backlog and lay the foundation for a successful development effort.
Listen to the audio version of this article:
1. Choose a Product Goal
A product goal describes a specific and measurable outcome a product should create during the next two to three months.[1] Sample goals are acquiring users, increasing conversion, generating revenue, or future-proofing the product by reducing technical debt.
Product goals offer the following four benefits: They describe the specific value a product will create in the coming months; they align stakeholders and development team; they focus the product backlog thereby making it easier to manage and update it, and they provide the context for choosing the right sprint goals, as I discuss in more detail in my article Product Goals in Scrum.
If you follow my product management approach and use a goal-oriented roadmap like my GO product roadmap, then you can simply choose the next goal on the plan as your product goal. If that’s not the case, then determine the outcome the product should achieve in the next few months, preferably together with the key stakeholders and development team members.
Ask yourself why it is worthwhile to progress the product and spend time, money, and energy on it. What is the specific problem you want to address or the particular benefit you want to achieve in the next few months? If you have a validated product strategy in place, you can use its value proposition and business goals to find the right product goal. Alternatively, use your key performance indicators (KPIs) to identify improvement opportunities. Then choose the most important one as the product goal, as I describe in more detail in my book Strategize.
2. Clear out the Product Backlog
Next add the product goal to the product backlog. Then remove all items that are not required to meet the goal. Delete or archive them. This might result in an empty product backlog that contains only the product goal. But that’s OK.
While this advice may sound drastic, it ensures that your product backlog is focused and concise. I have come across many huge product backlogs in my work, some of which contained several thousand items. All these backlogs had a common issue: They were not focused, and it was not clear, which specific value the backlog should help create.
Focussing your product backlog on a single goal makes it comparatively easy to prioritise and update. This is especially important for products that experience a significant amount of uncertainty, risk, and change—like new and young offerings—as their backlogs tend to be volatile and frequently change, as I explain in more detail in the article How Detailed should the Product Backlog be?
3. Determine the Items Necessary to Meet the Product Goal
After clearing out the product backlog, consider which product capabilities have to be created or enhanced to achieve the product goal. Say that your goal is to increase conversion by 5-10% over the next three months. Then ask yourself how you will achieve this outcome. How will the product have to change to meet the goal?
If you work with my GO product roadmap, then start by copying the features that are associated with the goal into the backlog. Additionally, answer the following four questions to discover the right backlog items:
- Does the user experience have to be adapted?
- Do you have to add or change any functionality?
- Do you have to meet new or enhanced non-functional requirements including compliance standards?
- Are bug fixes and architecture refactoring work required to address the product goal?
Keep the backlog items you’ve identified coarse-grained and sketchy, at least for now. For example, use epics to capture them but not detailed user stories. What’s more, the product backlog does not have to be complete at this stage, and I would argue that it should not be at this point in time. Remember that the backlog will evolve based on the feedback and data you gather by demoing and releasing early product increments to users and stakeholders. You’ll add new items, and you’ll remove or change existing ones.
4. Get the Product Backlog Ready
Once you’ve captured the work required to meet the product goal, prioritise the backlog. I recommend using risk as the main prioritisation factor at this stage. This will allow you to quickly address assumptions, and rapidly acquire the relevant knowledge. Risks may be related to the users, technology, business model, and compliance requirements. Here are four sample risks: First, users might not be willing to register before using the app. Second, the machine learning framework might not scale. Third, the price you want to charge might be too high. Fourth, a standard like GDPR, SOX, or HIPPA might not be fully met.
After prioritising the backlog, refine the high-priority items so that they are ready to start the development effort. The items should be clear, feasible, and testable. This involves breaking out smaller items from the larger ones, for example, deriving user stories from epics and adding acceptance criteria to the stories. You should now have a prioritised backlog with just-enough high-priority detailed items that can be worked on in the upcoming sprint.
When carrying out the work above, avoid two common mistakes. First, do not derive too many detailed items. Only create as many as the development team is likely to consume in the next sprint. This will result in an appropriately detailed and concise backlog that can be easily changed as you learn more about how to best address the user needs. Second, ensure that there are enough ready high-priority items to drive the work of the team in the upcoming sprint. Otherwise, it will be difficult, if not impossible, for the team to make a realistic forecast or commitment.
5. Make Stocking the Product Backlog a Team Effort
When you stock the product backlog, don’t do the work on your own as the person in charge of the product. Instead, involve the key stakeholders and development team members in setting the product goal. Additionally, ask the development team to help you discover, prioritise, and refine the backlog items—preferably in the form of a collaborative workshop. This approach offers you the following three benefits:
- You’ll leverage the collective knowledge of the group. This maximises the chances of choosing the right product goal and identifying the right product backlog items.
- You’ll create clarity. Stakeholders and team members have a clear and shared understanding of the goal. Additionally, the development team understands the product backlog items, despite them being sketchy and coarse grained, as the members have helped identify and capture them.
- You’ll secure strong buy-in. Inviting people to help set the product goal and determine the right backlog items increases the chances that the individuals are aligned, support the goal, and together move towards it.
If you follow my advice and employ a collaborative workshop, ask the Scrum Master to run it. This frees you from having to facilitate the session, and it allows you to actively shape the product goal and product backlog. At the same time, it ensures that everybody is heard, and nobody dominates. For more advice, please see my article Making Effective Product Decisions: Tips for Deciding with Stakeholders and Dev Teams.
[1] The product goal also features in the Scrum Guide released in November 2020. It states that “the product goal describes a future state of the product … [It] is the long-term objective for the Scrum team.” It also suggests that “the product goal is in the product backlog. The rest of the product backlog emerges to define ‘what’ will fulfill the product goal.”
Post a Comment or Ask a Question