Backlog Management: fine-tuned

Photo by Jo Szczepanska on Unsplash

Today we’re here to talk about backlog management and discuss how to optimize it for successful product development.

We’re all aware that the backlog serves as an emergent, ordered list of items that is needed to add value to the product. Backlog management, therefore, becomes a key responsibility of product managers, product owners or business analysts, encompassing various tasks such as prioritization, dependency management, backlog item creation and description, refinement, and estimation.

Numerous articles have been written on this topic, suggesting best practices for effective backlog management. My goal in this article is to share insights that I’ve learned throughout my experience and what I personally find valuable.

Some facts first

According to the McKinsey report from October 1, 2012 one of the top reasons for project failure includes unclear objectives, shifting requirements, lack of focus, and an unrealistic schedule.

If we delve deeper into this matter, we can recognize that, we can identify product backlog management as one of root causes for these project failure reasons. Let’s explore how backlog management is connected to these issues:

• Unclear objectives, shifting requirements: originates from improper backlog transparency and priorities. It must be clear what we’re working on, why, and what our next steps are. Transparent backlogs instantly show the consequences of any changes, allowing everyone to be prepared. Additionally, this transparency would also allow us to inspect why those changes happen so often. Lack of backlog transparency can lead to confusion among team members about the project’s intentions, and stakeholders might not be aware of what the team is busy with.
• Lack of focus: results from two major flaws: the team works on multiple assignments and finds it difficult to concentrate on one item at a time, or it’s where everything seems to be of the highest priority and needed “yesterday”. So yes, it’s also a matter of prioritization. Which brings us to the point that the proper prioritization is essential to help the team understand what to work on and avoid struggles in finding the right tasks to focus on.
• Unrealistic schedule: may be caused by a lack of team’s historical throughput data and, more importantly, the scope of the project. Missed dependencies and poorly described backlog items can lead to underestimating the project’s scope. Establishing traceability between backlog items and managing explicit dependencies can help uncover hidden impediments and blockers, leading to more accurate project planning.

Given the above, it becomes evident that proper backlog management is one of the key pillars for the success of product development. It plays a significant role in avoiding project failure. Now, let’s delve into the main topic of this article: how to effectively implement backlog management for optimal results.

Eliminate waste

I’d start with cleaning up. Since the backlog is the only source of truth, it must be reliable and easy to use. This involves ensuring searchability, availability of information, transparency, and keeping only necessary items. There is no room for irrelevant or outdated backlog items that may distract the team from focusing on what truly matters.

Here is a list of actions I would do to achieve this:

• Consolidate the backlog: Ideally, there should be a single source of truth for the backlog items and plans. While project management systems may not cover all our needs, it’s important to minimize the number of tools we use. Considering the various stakeholders involved, the backlog should be easily accessible to everyone.

For example, Jira today offers a vast range of capabilities that can cover almost all your needs: roadmaps, releases, dependencies management, etc. Therefore there’s no need to additionally use those spreadsheets, google docs and other things :)

• Be concise in the description: I used to be that person who wrote exhaustive requirements documents, 1–2 page use cases, and 8+ scenario acceptance criteria. I’ve come to realize that you’re probably the only one who actually reads and cares about it all. Over time, I’ve learned to focus on capturing only the essential and necessary information.

One approach that has proven useful for me is acceptance test-driven development. In simple terms, this approach involves writing acceptance tests before implementing the system (read more about ATDD). In most cases, all you really need to capture in the acceptance criteria is the system’s response to a specific action. By concentrating solely on this, you can keep the description concise and straightforward.
Example of “acceptance tests” approach:

And believe me, I could easily write a 2–3 page use case document to describe the requirements from the example above, but what for?
However, I do understand that it’s not always feasible to condense the description into a simple table. Nevertheless, it’s still worthwhile to emphasize the importance of keeping the description concise and focused on the key points only.

• Create backlog items only when necessary: While the suggestion to record all ideas and improvements may sound appealing, it can lead to a cluttered backlog. Instead, the backlog should primarily consist of items planned for short or mid-term implementation.

It doesn’t mean that you should not record these future ideas/plans at all. Just ensure it’s kept aside from the relevant work that is planned to be done in nearest time. In case you use the Atlassian stack, keep all those “future” things in a separate confluence page, or label them in Jira and hide in the normal backlog view via filtering, so it’s not mixed up with the backlog items planned for delivery.

Use sprint goals for midterm planning

To enhance planning transparency, consider assigning sprint goals for multiple sprints in advance. These goals serve as preliminary indications of intentions and align expectations. Among other things, assignment of sprint goals for a few sprints ahead would help the team gain a sense of the overall direction and inform stakeholders about upcoming deliveries.

For more detailed information on using sprint goals, you can refer to my dedicated article on this topic.

Epics are big stories, not buckets

This is a common issue that I have encountered frequently and even made the same mistake myself. Books say that an epic is intended to be a large user story that cannot be delivered in a single sprint or iteration. It serves as a higher level of abstraction, which should be further specified and broken down into more granular and specific user stories.

However, what I see frequently instead is that epics are treated as buckets for various tasks, user stories, incidents, bugs, and so on. If your epics are named “Admin panel features”, “Authentication & authorization”, “Profile management”, or something similar, then you have fallen into the same trap I used to fall into.

Let me explain why this approach is problematic and the consequences it entails::

• Undefined scope: Such epics lack a clearly defined scope, making it difficult to close them as new issues and tasks continuously get added, somewhat relevant to the epic’s theme. As a result, tracking progress becomes complicated.
• Lack of goal tracing: The different levels of abstraction in the backlog should have a clear traceability from high-level plans and goals to low-level delivery tasks or user stories. When an epic is treated as a group or bucket, this chain of traceability is disrupted, and there is no clear correlation to the initial objectives.
• And as a result from above: planning becomes challenging for such epics because there is no clear expected outcome when the epic is finalized.

To address this issue, treat epics in the same way as user stories: they should have a clear description, goal, acceptance criteria, and/or test scenarios. This way, you will always know when you have reached the end of an epic. From there, you can slice user stories based on the acceptance criteria or test scenarios.

Be mindful with epics decomposition

When decomposing epics into stories, it is crucial to be mindful of the approach. It might not be that obvious, but incorrect decomposition can actually slow down the team and jeopardize the success of the delivery.

As an example of incorrect decomposition I can come up with the “type of work-based decomposition” or “technology layers decomposition”, when you create separate tasks for design, back-end development, UI mark-ups, testing, deployment, and so on. This example breaks the whole idea of user story, as each story won’t be testable or bring any business value.

Instead, focus on the acceptance criteria and create a user story for each acceptance criteria of an epic (which aligns with the earlier point that “Epics are not buckets”: epics must have defined acceptance criteria and scope). This allows for faster value delivery rather than waiting for the entire epic to be completed.

Visualize backlog

As was previously mentioned, transparency is crucial in product development overall, particularly when it comes to product backlog management. To achieve transparency, I recommend the following practices:

• Visualize long and mid term plans: to bring transparency in plans we could create visual representations of the product roadmap, release plans, and other planning artifacts. However, visualization alone is not enough: regularly review these plans with all stakeholders to ensure they remain relevant and make any necessary adjustments.

“Sprint Review” meeting is actually a great place to examine where we are now and where we’re moving further. This meeting provides an excellent opportunity to assess the current state of the increment and review the product roadmap, release plans, and other planning artifacts. Use this time to determine if any adjustments are needed.

• Visualize priorities: priorities have to be understood and visible not only for you as the one who assigns them, but to everyone involved in the product development process. As mentioned before, ensure there is only one source of truth for priorities.
• Visualize dependencies & blockers: as dependencies inevitably impact your planning and prioritization, and it’s crucial to have them explicitly visible and be available to everyone involved. This visibility would help managers understand what impedes the team’s progress and allow development teams to align their next steps accordingly.
• Make Definition of Done (DoD) available and accessible: merely documenting the DoD is insufficient. It’s crucial to verify that the development team adheres to it and comprehends its requirements. Regular DoD reviews can help identify whether the criteria are too loose or overly complex to adhere to.

Track backlog health

And the last, but nonetheless important, is to monitor the health of your backlog. Here are a few metrics I’d track to ensure my backlog is in a healthy state.

• Refined 1–2 sprints ahead: Aim to keep the backlog refined at least one sprint ahead, with two to three sprints ahead being the ideal range. However, avoid excessive refinement as it may result in wasted effort due to emerging knowledge and evolving clarity that renders estimates inaccurate.
• Obsolete backlog items: I’d also regularly inspect the backlog to identify and close items that are no longer relevant: there can be duplicates, irrelevant bugs, outdated backlog items you decided not to implement, etc. The frequency of this inspection/review can be determined based on ticket creation rates and the volatility of your domain.
• Not compliant with Definition of Ready (DoR): Ensure that all backlog items (stories, epics) align with the criteria specified in the DoR. In tools like Jira, you can easily query the list of items that lack the necessary attributes.
• Defects rate: I’d also track the number of bugs assigned to each component. This allows you to create dashboards indicating which components are more prone to bugs, enabling you to allocate QA resources accordingly.

Closure

That concludes the insights I wanted to share this time. Feel free to provide comments and share your own experiences that have helped you in the field of backlog management.

Cheers!