What if there was no backlog?
The biggest backlog I’ve ever come across contained around 3,500 items! I can’t imagine any product owner or team who could really understand what was in it.
It got me thinking – why did it happen in the first place? One of the conclusions I drew was that product owners, not wanting to say ‘No’ to their stakeholders, say ‘Not now’ and add their requests to the backlog. Realistically, most items in the backlog never get done, but the loss aversion bias prevents us from getting rid of these requests. So the backlog keeps growing.
The short term result is good – the product owner does their job and documents the request for later, the stakeholder is informed that it might take some time to deliver the request, but it can be done and the team carries on with what they were working on. Everyone happy.
But there is a dark side to this approach.
Usually, the backlog (a.k.a demand) grows faster than the capacity of the team. This means:
- The number of items in the backlog grows, so simple tools might not be good enough to provide a backlog for the team anymore.
- Backlog grooming sessions are now longer and/or more frequent.
- Stakeholders wait longer for their requests to be delivered (partially because the queue is longer and also because the team is busy grooming the queue for longer or more often).
- Some new requests jump the queue because they are small, which makes the waiting time for older backlog items even longer.
- Some work becomes super urgent (deadlines!), which means the developers need to drop everything they were working on and switch the context to the urgent tasks.
- Rushing to complete the code leads to low quality output and technical debt.
- Stakeholders subconsciously start counting time from the moment they hear ‘it’s in the backlog’, so they are going to get frustrated at a later stage when they discover that their request has not been picked up yet.
Less is more
Have you noticed that most restaurants don’t accept more customers than they can serve at any given time? In some cases, they advise on a waiting time. If it’s reasonable, some people wait, but a lot of them will simply go somewhere else and still have a good time.
Your stakeholders might not have an option to go somewhere else though. Managing their expectations is even more important in this case. It’s more difficult compared to the ‘Not now’ approach, but always works better in the long term. My advice would be to try working with the stakeholders at this point and decide together on what’s the most important thing to do. Agree on a limit for the number of backlog items and if there is something which is more important than other items in the queue – remove a backlog item that is considered the least important at that time. A nice trick here is to exchange a number of tokens between the team and the stakeholders. A completed request = a token returns to the stakeholder and there is a space for a new request.
A thought experiment
What if there was no backlog at all? Imagine this:
- Every time the team completes an item, there is a negotiation with the stakeholder on what the (one) most important thing to do next is.
- There are no backlog grooming sessions.
- There are no extra tools needed for managing the backlog.
- There is no jumping the queue problem, as there is no queue. The team is already working on the (one) most important thing.
- Lead time (time from the request till delivery) and cycle time (actually delivering the request) are the same.
- There is a slack in the system (and there is nothing wrong with people not being 100% utilised!).
But is it possible to not have a backlog in real life?
Probably not, but trying to reach a fantastic but unachievable goal still leads to improvement.
So, dump your old backlog and start afresh. Keep it short. Delete stuff. Important requests will always bubble up again. Unimportant requests will go away.
Less is more.
Anna Miedzianowska, Product Manager