5 Attributes of Healthy Backlogs
Having a healthy backlog creates an environment with good morale, high confidence, and positive energy. Healthy backlogs make business goals visible, provide a sense of security, and reduce the risk of disruption from random, unplanned requests. All these things make me, and the team I’m working with, feel good.
In this post, I want to explain to you 5 key attributes I look for when deciding if a backlog is healthy or not.
Transparent
If only part of the team and/or the Product Owner can understand the items on the backlog then it is not transparent. Transparency requires an equal, shared understanding of the items in the backlog by all team members.
Refined
Items at and near the top of the backlog must be refined.
They need to be well understood, reasonably sized, and ready to be worked on. This ensures there can be a steady flow of work pulled by the development team. These attributes aid the overall backlog health as explained below:
Steady flow of work
The product backlog needs to have enough refined items to cover the next 2 or 3 sprints, ensuring the delivery team has enough work and won’t be delayed by trying to work out what can be worked on next.
This also provides enough slack and freedom for the Product Owner to (re)order the backlog to maximise value across the upcoming sprints. Where there’s only enough refined work for the next sprint, the Product Owner has no flexibility or capacity to respond to change should the situation require it (for example: risk)
Size
When items are too large to be delivered completely within a sprint they are too large to be at the top of the backlog.
“Size” doesn’t mean they are estimated in Fibonacci-based story points, it simply means that the development team has confidence the items can be delivered within a single sprint. Items that are too large will disrupt the steady flow of work and need to be split up.
Note: Focusing on numerical sizes may not be that valuable. The value in estimation and sizing isn’t in coming up with the estimate, it’s the process of estimation itself. Performed properly, the act of sizing uncovers assumptions and unknowns and is invaluable in creating the shared understanding we desire through the process of team discussion and debate.
I’ve written about this in the past. When there is healthy discussion and debate, questions are regularly raised that highlight misconceptions and false assumptions, and that show further conversation and clarification is required to reach shared understanding. It’s this process that generates the greatest chance of successfully delivering value.
Keep in mind that story points are not the only approach to estimation. I’ve often favoured T-Shirt sizing because it reduces arguments over which estimated points value is “more correct”, and keeps the focus on reaching a common, shared understanding amongst team members rather than a granular numerical estimate.
Organised
A healthy backlog has to be organised in a way that is understood by all.
Hierarchical
Organising the backlog into a hierarchy of epics, features, and stories is a common pattern for healthy backlogs.
If you organise your backlog hierarchically, I recommend never having unparented user stories and never using a generic, placeholder parent feature for times when you feel lazy. If you have an epic or feature which you use as your first option when a user story becomes hard to categorise, I suggest you re-examine your backlog as you are likely missing an epic or feature. We don’t want a “too hard to think about now” bucket for user stories. It erodes team confidence.
Ordered
A backlog needs to be ordered to maximise value out of the development team. This is often correlated to business priority, but as my colleague Richard says “there are two priorities: ‘very high’ and ‘very very high’. In some places there is ‘very very very high’".
If your Product Owner struggles to order the backlog in a meaningful way, encourage them to order according to two dimensions; risk and value. Place the “high risk, high value” items at the top. If risks arise that may jeopardise the project we want to know as early as possible. Next on the backlog, place the “low risk, high value” items, followed by the “low risk, low value” items.
I advise Product Owners to drop any “high risk, low value items” from their backlog. It makes no sense to take a high risk to build something that will only deliver small value.
Consistent
Items in the backlog should show consistency.
Write acceptance criteria with a consistent structure to improve understanding and reduce chances of miscommunication.
If you use and name personas, it’s important to keep them consistent for the same reason. It reduces noise in the backlog and streamlines the thinking of the people reading the backlog items.
Consistency in structure will ease the mental burden for the delivery team when looking at the backlog.
Collaborative
Finally, a healthy Product Backlog has to be collaborative.
A Product Owner isn’t a Product Backlog Owner. Anyone in the team should be able to contribute new items to the backlog and to collaborate with the Product Owner to further improve items not yet started. The Product Owner’s responsibility is to maximise the value delivered by the development team. Encouraging collaboration and contributions from the development team further improves their morale and can be a surprising source of new, valuable ideas that the Product Owner may not have considered.
Similarly, being open to change includes removing items. In long-lived backlogs it’s not unusual to have many items which are no longer relevant, where the original context has been forgotten, or where the potential value has eroded over time. Items that are poorly worded, not transparent, are simply not understandable by the people that are now on the team. Don’t be afraid to delete these items. Keep the weeds out of the garden!
A Big Thank You
I would like to thank Richard Banks for helping me write this blog post. You can see how we collaborated on this blog post on these pull requests.