The biggest backlog I came across contained around (!)3500 items… I can’t imagine a product owner or a team who would really understand what’s in it.
It kept me thinking – why did it happen in the first place? One of the conclusions 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.
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, the team carries on with what they were working on. Everyone happy.
Well… There is a dark side of 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 partially 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 thing
- rushing to complete the code leads to low quality 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 ‘Not now’ 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 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 when the team completes work, there is a negotiation with the stakeholder on what’s the (one) most important thing to do next
- 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 already works 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 great goal which is not possible to reach, still leads to improvement.
So, dump your old backlog and start afresh. Keep it short. Delete stuff. Important requests will always bubble up. Not important ones will go away.
Less is more.