Raph’s Blog

Healthy Backlogs

When I look at a healthy backlog, I feel that I’m going to achieve something, there’s often a sense of security within the team, and a healthy backlog generally means there’s little unplanned work being thrown towards the team. Feelings are important to the team and its members, and a healthy backlog can help with mood and emotions. In this post, I want to explain to you what I think the specifics are when I think of a healthy backlog, which, may help with mood but will certainly help with delivery.


The backlog has to be transparent. If only a small subset of team members or the Product Owner understand items on the backlog then it is not transparent. Having transparency in the backlog means that there is a broad understanding of items for the next few sprints in the backlog. This understanding shouldn’t be limited to a few members of the team but should extend to everyone within the team.


Related to transparency, the Backlog has to be refined for the next few sprints. A part of this is two things: having a steady flow of work and having reasonable item sizes (I’m not saying things have to be ‘sized’ or ‘estimated’ here, so please don’t stop reading if that is your preference)

Steady flow of work

The backlog needs to have enough refined items for 2 or 3 sprints. The reason for this is so that the delivery team doesn’t run out of work. The more important reason though is so that there’s enough slack and freedom for the Product Owner to order the Backlog to maximise value for the next few sprints. If there’s only enough items for 1 sprint coming up, then the Product Owner really doesn’t have any freedom or choice to change the order of the Backlog if something changes (for example: risk)


When I say ‘size’ here, I don’t necessarily mean that items have to be estimated in Fibonacci points. What I mean is that for the next 2 or 3 sprints the size of the items have to be deliverable within a sprint length. If items are too large to be delivered within a sprint length or if items are too large to be sized then this should be a signal that items are not refined and can’t be worked against. It means we need to break up the user stories in smaller user stories.

Actual numerical sizes may not be that valuable, however, the value in sizing isn’t necessarily the size itself, but the act of sizing. The act of sizing uncovers unknowns and can normalise understanding through team discussion and debate. I’ve written about this in more detail here. When there is healthy discussion and debate, there are often situations where estimates can’t be given because user stories need clarification. This is an example where sizing can be valuable. For these reasons, I’ve often favoured T-Shirt sizing, because if done properly, it can produce a common understanding amongst team members but not demand unnecessary attention to specific estimates.


A healthy backlog has to be organised and organisation doesn’t mean complexity. In fact, it’s quite the opposite it means simplicity and this will aid in my first point about transparency. Having a simple backlog is easier to understand than a complex one.


Depending on the size and complexity of your product or project, it may be a good idea to organise the backlog into a hierarchy of epics, features, and stories. If you do choose to do this, I would recommend not to leave user stories without parents or in a generic parent in the backlog. I want to emphasise, if you have an epic or feature which is the first option when a user story becomes hard to categorise, I would suggest a re-examination of the hierarchy. We don’t want a “too hard bucket for user stories”.


A backlog needs to be ordered to maximise value out of the development team. Often, this is 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’“.

So how is it that we need to coach our Product Owners to order a backlog to minimise risk and maximise learning? We train our Product Owners to order according to two dimensions. Risk and value. We do the high risk, high value items first, so that we know if there are any issues that may jeopardise the project, followed by the low risk, high value items; followed by the low risk, low value items. We advise our Product Owners to never actually tell the team to deliver high risk low value items as it doesn’t make much sense to take high risk for something that will deliver very little value.


Ideally, there should be consistency in the backlog. There are many ways to write acceptance criteria but let’s keep it consistent. Likewise, there are many ways to name personas but it’s important to keep them consistent. The value in consistency is that it reduces noise in the backlog and streamlines the thinking of the person who is supposed to be looking at and reading the backlog. This behaviour may implicitly encourage the delivery team to look at the Backlog more often than if the backlog isn’t consistent.


Finally, a healthy Product Backlog has to be dynamic. A Product Owner isn’t a Product Backlog Owner. A Product Owner has to trust the team so that any member is able to modify items in the backlog, however, it is the Product Owner’s responsibility to order the backlog to maximise value from the team.

The Backlog has to also be open to change and this includes deleting items - en mass! If it is found that the Backlog has many items which are high risk low value, not transparent, not understandable by most people. Then we should not be afraid of deleting these items.