Product backlog: guidelines and best practices
I’ve been in Product Management for over 10 years now and I’ve picked up a thing or two along the way. In this post, I’m explaining my Product Backlog best practices. Creating a sorted list of software requirements sounds straightforward. In practice, however, exactly the opposite is the case.
Have a Pre-backlog Before the Actual Backlog
One of the worst things you can do is to use the Product Backlog as an idea pool (“we may need that in the future”). This inflates the Backlog with unnecessary ballast in the form of a wish list, which in case of doubt creates no added value for the user. A Pre-Backlog, for example a Trello board, a Confluence page or another suitable medium is a better choice to collect ideas which have not been validated at an early stage:
There Is Only One Source of Truth
I’m an advocate of one Backlog per product. I’ve seen constellations in which a “Technical Debt Backlog”, a “Sales Backlog” and a “Customer Care Backlog” existed. The desire is often to give everyone a piece of the cake (development capacity). The reality, however, is that the PO is now confronted with heterogeneously formulated Backlog Items and has to try to create a kind of Frankenstein Sprint Backlog. It is easier and more transparent to manage all entries in one Backlog, be it user stories, bugs, technical debt, refactoring, spikes, retrospective issues or configuration tasks.
Don’t Look Back in Anger
Just close old and low priority items. A Product Backlog is not a collection box for random ideas, it is a curated list of high priority user problems that need to be solved. Having items on your Backlog which will never make it to a Development Sprint is expensive. You constantly have to prioritize those apples and oranges and discuss their status with stakeholders. Just close them.
If your backlog management software supports it, you could also setup a rule to automatically close items which have not been updated in the last e.g. 90 days. Those issues are not deleted, they are closed and can be reopened. But they are out of the way for now.
“No, because”
POs who are afraid to say “no” to feature requests tend to end up with overcrowded Backlogs and spend time providing information about the status of individual items. A “no” creates clarity for both sides and is better than a “maybe”. A “no, because” is desirable, as it assumes that the request has been weighed against other issues and consciously refused.
Ruthless Prioritization
Ensuring the desired order of Product Backlog items at all times is one of the key responsibilities of the Product Owner. If you are new to the role it might sound straightforward, but you need to take into account that every shipped User Story equates to an investment decision. The investment takes the form of the Product Development Team’s working time. The personnel costs of such a team depend on the company, the seniority, the location and the team size. Per sprint it can easily reach a five-digit amount in the full cost analysis.
Translated to the operational level, the Backlog must always provide an answer to the developer’s question: “What is the single most important thing I should be working on now?”
Alignment With the Product Goal
If the team works according to Scrum, a change in the Scrum Guide has to be taken into account when prioritizing Backlog Items. With the 2020 update, the initiators of Scrum have added a commitment to the Product Backlog: The Product Goal. The idea of the Product Goal is to provide context to the Product Backlog and answer the question of why the team is doing all of this work.
The Product Goal should not be confused with the Product Strategy. While the goal is, for example, “reach 500,000 active users by the end of the year”, the strategy rather focuses on the long-term orientation of the company and market-based thinking in terms of competitive advantages.
When You Inherit a Messy Backlog
As a freelancer, I regularly join new Product Development Teams and inherit a Product Backlog. Either it is a well-organized list of requirements that I can continue to work with seamlessly. Or if it is badly organized, I have changed my approach in recent years: I don’t reorganize messy Backlogs anymore. I am convinced that it is more efficient to start with an empty Product Backlog and iteratively transfer important items to it.
Use a Prioritization Framework
A prioritization framework uses consistent and comprehensible criteria to sort items in descending order. Typically the criterion is the contribution to the company’s success. In addition, a prioritization framework ensures that:
- An objective evaluation of all requirements takes place
- Prioritization decisions are understandable for stakeholders
- The Product Owner’s self-bias is minimized
There are a number of prioritization frameworks with different variables and objectives, for example:
- Value vs Complexity
- Weighted Shortest Job First (WSJF)
- Cost-Benefit Analysis (COBE)
- RICE Scoring
- Kano Model
- Opportunity Scoring
- Impact Mapping
- MoSCoW
- Eisenhower
An excellent assessment of the various frameworks in terms of their focus and complexity is How to choose your Product Prioritization Framework.
Update Frequency
The Product Backlog is a dynamic list of requirements, it is never complete, and it evolves over time. Nevertheless, the Product Owner should weigh up the frequency and extent to which he applies changes. It does not indicate good planning if larger areas of the Backlog change at short notice. After extensive changes, all stakeholders have to reorient themselves and understand the changes compared to the old status. In the sense of Agile Software Development, incremental changes are easier to understand for all involved parties.
Sprint Pre-Planning
Agile Software Development is often accused of poor predictability. If the team works according to Scrum, exactly the opposite is the case. Scrum is based on fixed iteration cycles that allow forecasts about software shipping milestones.
The long-term orientation is based on the Product Vision, operationalized in the form of Product Backlog items. The short-term orientation is provided by the Sprint Backlog, so the selected items to achieve the iteration’s Sprint Goal. However, in everyday project work, the medium-term planning level with a horizon of a few weeks is often the decisive one. One approach for medium-term planning is Pre-Sprint-Planning:
The idea is to create future Sprints in the Product Backlog and already fill them with items. For the Development Team and the stakeholders involved, this approach has the advantage of recognizing dependencies earlier and being able to better estimate the expected completion dates.
However, it is important to find the balance between pre-planning and commitments. The idea of this approach is to provide an outlook, it is not about committing to a certain scope on a specific date. It has to be possible to inspect and adapt at any time and adjust the prepared Sprints accordingly.
The Product Vision is Recognizable
A good Product Vision appeals to the deeply anchored drive of every individual to do the best of their own free will, regardless of the employment contract, because they are convinced to make their contribution to something meaningful.
In order to recognize the Product Vision in the Product Backlog, you have to read between the lines, which is possible in well-organized Backlogs. For example, the number of different Epics on top of the Backlog can be an indicator of whether the team is concentrating on the Product Vision or is fulfilling too many different requests without a clear focus:
In addition, the way in which Epics are sliced is an indication of the Product Vision’s importance. Epics such as “Customer Care Feedback” can turn into a collection pool for an indefinite period of time without any connection to the Product Vision. As an alternative, customer care feedback can be added to a more concrete Epic such as “Update order quantity after an order has been placed”. This Epic describes a clearly defined user scenario and will be closed after the Product Increment has been shipped.
Group Items in Meaningful Units
A well-organized Backlog is broken down into smaller chunks of work. Those smaller chunks are called Epics and group related User Stories.
Creating Epics is straightforward, but the way Epics are sliced is not. An anti-pattern are horizontally sliced epics, where horizontal refers to the technology stack. “Frontend improvements” is a typical example of this. The Epic comprises a clearly delineated part of the technology stack and has no identifiable target. It is better to slice your Epics vertically with a clear user scenario. For example: “Recurring payments with PayPay” or “Withdraw cash in Euro”. These Epics include something from each layer (UI, PSP, backend and so on) and can be closed when the user scenario is successfully completed.
Severity vs. Priority vs. Item Position
One of the core characteristics of a Product Backlog is a clear prioritization. Nonetheless, in daily doing it can be difficult to see which item the software development team should pull in next. Often it is a tooling problem, or more precisely a configuration problem in the common solutions to organize agile software processes. Why? Tools offer different prioritization dimensions:
- Severity: the classification according to severity is used in bug tracking and incident management. Typically, the severity describes how bad an issue is and within what period of time someone should look at it. It is supposed to be objective, but as humans decide on the level of severity, it will always be a subjective classification.
- Priority: the priority is subjective and is based on the importance that the creator ascribes to his requirement. Since the creator will rarely assign a low priority to his idea, a neutral evaluation scheme is required to ensure an objective classification (see “use a prioritization framework”).
- Backlog Position: the forced item ranking.
In order to clear up this confusion, a consensus decision is required. The team needs to decide on the categorization approach, making it unmistakably clear which item the software development team should work on next.
Work of the development team without changes on the application’s code also needs be visible in the Product Backlog. For example in the form of a Spike with a defined goal (“Research new framework”) and a time box. Including non-coding tasks as Product Backlog Items has several positive effects:
- Resource planning and utilization become more precise.
- Time dependencies become clear: the Spike first and the implementation afterwards.
- Research is sliced out of the actual implementation story.
- Transparency in terms of decision-making (“Why a certain framework has been selected”).
Have an Analogue Version
Especially if the Development Team works at the same location, it is advisable to visualize the Backlog in the form of a physical board. It is conducive to the conversations between the team members, clarifies the progress of individual issues and is helpful in the early phases of team building. In addition, transparency is created for other product teams in order to recognize dependencies more easily.
Backlog Editing Permissions
It is tempting to give stakeholders the permission to create User Stories in the Product Backlog. What at first seems like a time saver often turns out to be the opposite. For example, User Stories created by stakeholders may not comply with team’s Definition of Ready (DoR) and therefore have to be reformulated by the PO. And even if the User Story complies with the DoR, it costs the Development Team additional time to identify the key points in a new writing style. Possible solutions to deal with this are:
- A restrictive Product Backlog setup (only the Product Owner can add Items)
- Use the JIRA workflow (stakeholders are allow to add Items, but the PO has to accept them before they get added to the Backlog)
- Provide clear guidelines: stakeholders are allowed to add requirements but with clear guidelines
Reader-Friendliness
Last but not least, write for your readers like you develop products for your users. First of all, reader-friendly User Stories have a concise title. It should not be too short (“fix this”) or too long. Long titles are difficult to read on a Scrum boards and hard to remember. Concise titles which summarize the work to be done are for example:
- Add tablet breakpoint to sign up form
- Send event tracking on web player crashes
- Update to Angular version 10
The reader-friendliness also includes a web-compliant writing style: use short sentences with a clear message, no incomprehensible box sentences. Avoid filler words (also, really, obviously), as product backlog items should clearly describe the result for the user.
Well, these were my product backlog management best practices. Thanks for reading.
[1] The Scrum Guide, https://www.scrumguides.org/scrum-guide.html
[2] Product Vision, https://www.joelonsoftware.com/2002/05/09/product-vision/
[3] https://uxdesign.cc/how-to-choose-your-product-prioritization-framework-ff0320d63ebf
[4] https://www.atlassian.com/de/agile/project-management/epics
[5] https://community.atlassian.com/t5/Jira-questions/Severity-vs-Priority/qaq-p/271844
[6] https://www.thoughtworks.com/insights/blog/story-mapping-visual-way-building-product-backlog
