5 Dimensions of Healthy Backlog

One of the areas that I have seen Agile teams having difficulty is in maintaining a healthy backlog.

The impact of not having a good backlog impacts many  activities for teams.

Starting with ambiguity in terms of release planning – or planning ahead and moving to identifying dependencies – particularly technical risks or ensuring that the delivered solutions meet the users’ expectations could all cause surprises and delays.

By focusing on a good, healthy backlog, teams can focus on ensuring a smooth and fast flow to value of the backlog items while steadily improving their own effectiveness.

I would like to recommend that teams focus on five major areas to create healthy backlogs.

While each of these would require separate discussions by themselves, this post is an overview of these areas.

1. Sufficient volume or depth

This could be a debatable point, as many practitioners tend to interpret Agile approaches to say that we need to groom stories just in time, which is just before a sprint starts. Based on our experience, this tends to compromise on the attention to detail for the essential architecture or design aspects. Moreover, the coordination with other teams becomes difficult when the visibility is very short. The recommended depth for a backlog should be to have sufficient stories for at least a quarter ahead. That could  translate to up to six sprints, if the team has adopted a two week sprint

2. Prioritized

The backlog should be prioritized progressively. While in the initial stages it may contain a dump of all stories – more as a wish list, it needs to be progressively elaborated and prioritized. The prioritization step will help the teams balance both technical and functional stories together so that risks and dependencies can be addressed as early as possible

3. Aligned to Roadmap

It is important that the prioritized stories are grouped and sequenced in alignment with the desired roadmap. techniques such as story mapping will help pick all related stories to enable a full business transaction to be completed in a release. This will ensure that any refinements along the way can be more easily incorporated as the functionality will evolve progressively deeper.

4. Refined

The prioritized backlog needs to be refined periodically. It is recommended that a story is adequately refined to be ready at least two sprints ahead, so that other dependencies – such as UI elements or other teams’ deliverables can be identified early and sufficient leads times are available. Using the INVEST criteria will help determining the readiness of a story to be taken up for implementation

5. Consolidated backlog

Some teams tend to maintain different backlogs for functional stories, technical stories and support issues. It is best if all the requirements are consolidated into one backlog so that the relative prioritization is easier. This will also help teams get the bigger picture of all that is expected.

To remember these attributes, just remember SPARC!

Which of these do your backlogs exhibit?

If you use any other dimensions that has worked for you, please share your experience with those techniques for the benefit of the community.

What do you think?

Leave a Reply

What to read next