A healthy, well-managed product backlog makes communication easier, provides transparency, and enables the flow for delivering valuable outcomes at a sustainable pace. It reflects the investments your business leaders are making in your product and provides near real-time data and visibility into work delivery. In short, getting backlog management right has a positive cascading effect for Agile teams and businesses across industries, including healthcare, finance, insurance, and more.
In Part 1 of our series on Taming the Backlog, we looked at three common anti-patterns of backlog ownership, and other characteristics of unhealthy backlogs. Now that we know what to avoid, let’s dive into what items you do want in a healthy product backlog and the characteristics you can focus on to strengthen it even further.
The Contents of a High-Quality Backlog
If the product backlog is a software product development team’s to-do list, what types of items should be included? Below we define the most common components that, while well-known to Product Owners and IT leaders, should also be understood throughout your organization to ensure backlog health. Keep in mind that Agile frameworks define product backlog items differently, usually due to scale or size.
- Epics – Epics are large bodies of work that can take six to twelve months to complete. They get decomposed into smaller increments including features and stories. Performance and stability work are good examples of epics. Another example is adding a shopping cart to an e-commerce website or mobile application.
- Features – Features are smaller than epics and larger than stories, typically taking one to three months to complete. Features get decomposed further into stories. An example of a feature is one-click checkout in an e-commerce website or application.
- User Stories – User stories are considered the most common product backlog item, as product development teams are generally customer focused. Stories should be small enough in scope to be completed in a single sprint or less. Examples of user stories for the one-click checkout feature are (1) to allow a user to activate one-click checkout within their account and (2) to require the user to select a default payment method. User stories do not have to be associated with a feature or epic.
- Technical Stories – Technical stories are often enablers or involve paying down technical debt. These should also be small enough to complete in a single sprint. An example of a technical story is to add error logging for troubleshooting purposes. Technical stories should have business justification the same as any other work. Some technical stories, such as version upgrades for software that will no longer be supported, simply must be done.
- Bugs and Defects – Bugs and defects are discovered through testing or actual end user activity on a live product. From a product backlog perspective, they are like a story in that there should be sufficient detail, including steps to reproduce the issue.
- Spikes – Spikes, also referred to as research stories, usually come out of product backlog refinement. Sometimes you just don’t know what you don’t know. Once identified, a spike should be added to the current sprint backlog, which can impact the other work planned for the sprint or iteration. Therefore, spikes are not blank checks. Exit criteria should be defined and the time box respected.
With so many different types of items, it’s easy to see how a product backlog can get messy quickly. Even in the acceptable scenarios for product backlog ownership (see Part 1), it takes consistent effort to capture, refine, socialize, and prioritize these items. It also takes time to communicate changes in overall priority so that transparency and stakeholder expectations are maintained.
More Characteristics of a Healthy Backlog
To create a framework for a healthy backlog, you’ll need to focus on more than just the specific items included and how they’re categorized. Use these additional characteristics as your guide in assessing your current backlog and strengthening it further.
A healthy backlog is:
- The Right Size. Set a limit for the number of items allowed in the backlog–100 items or less, generally. The right size can also be equated to the number of items projected for the next four iterations.
- Current. Items should be less than 9 months old. Newer is better, though it’s important to keep in mind that some epics can take 6 or more months to complete. With the pace of change at the backlog level, accept that the older an item gets without being worked on, the less likely it is to ever be worked on.
- Actionable. Have two iterations worth of work ready and prioritized for the team. This is easier said than done given the rate of change that teams deal with, yet critically important to keep the flow of value delivery consistent. This alone makes dedicated product ownership non-negotiable; it is a full-time job.
- Balanced. New features, production support, tech debt, and innovation/process improvement items all vie for priority. It is possible to balance time invested in the different types of work.
The idea of current items likely leaves you with a looming question about backlog size and long projects. How can you confidently estimate a project longer than a few months, if the healthy size for a backlog is relatively small? Keep in mind that backlog size is about minimizing waste and reducing complexity. By keeping focus on the next few iterations in the team backlog, time is not spent defining work too far in the future, which is likely to change in nature or scope. Estimating Agile programs or projects is possible without cluttering your backlogs, and the Agile Enablement experts at Polaris can help you tackle that as needed.
From there, team capacity and time are fixed, and there is generally more work requested than an Agile team can do. Given that, striking the right size and balancing priorities are two of the most critical characteristics from the list above. They’re key to keeping your backlog current and actionable. In Part 3, we’ll outline ways to trim your backlog down and ensure it stays objectively prioritized.
Back to Blog