5 Tips for Stocking the Product Backlog
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 backlog in the right way. This article offers five tips to successfully stock the product backlog and get it ready to develop the product.
🎧 You can listen to the audio version of this article on my podcast: https://www.romanpichler.com/podcast/
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.
Read On …
To read the rest of this article and access the remaining tips, please head over to my website: https://www.romanpichler.com/blog/5-tips-for-stocking-the-product-backlog/
Learn More
You can learn more about successfully working with product goals and the product backlog by attending my product owner training course and by reading the second edition of my book Strategize.
Note
[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.”
Source: https://www.romanpichler.com/blog/5-tips-for-stocking-the-product-backlog/
