To be honest, we don’t do backlog grooming sessions too often. By focussing on what’s at the top, we believe that everything else simply doesn’t matter. Yet.
This down-to-earth approach can get out of control, especially when anyone from the team can add backlog items that need work ‘at some point’. When not watched, this can lead to a fat and ugly backlog over time, where user stories are waiting forever to get done. Seriously – having a small agile team and 100 items in the backlog – do you really believe that item #100 will ever be done?
Knowing our velocity, it would take about 8 months to complete all the backlog items. That is assuming that no new bugs, important requests, or the need to rework an item doesn’t appear in the meantime. In theory, any new request would need to wait 8 months. That’s not very agile, is it?
If in doubt – remove
One day we decided to challenge the situation and leaving just 4 top stories in the virtual Lean Backlog box, we moved all the other backlog items into a virtual bin.
Seeing all the backlog items in the bin came as a bit of a shock to the team at first, and the loss aversion bias kicked in: ‘We can’t just delete the whole backlog!’ the team said. ‘Can’t we? Can you even tell what is in the backlog at the moment?’ – I asked.
Sell it or lose it
The first task of the session was to sell each backlog item to the team, or in other words – prove its importance. Questions we were asking were along these lines:
- What’s the real impact of this item?
- Who are the stakeholders?
- What’s the cost of delaying this item?
- What’s going to happen if the item is not done at all?
- Can we justify working on this item within next 3 months?
- Is this really so important if nobody chased that issue for so many weeks/months?
Surprisingly, we realised, that we didn’t even remember adding some of the items to the backlog, let alone being able to explain them in details. In the end, only 40% of the items managed to get out of the bin. That means – 60% of the backlog items deserved to be deleted!
All remaining items had to go through prioritisation process – comparing business value and development effort required.
This approach, leaving us with a healthy backlog with only essential items, was inspired by company called 37signals and their book titled ‘Getting Real‘, which you can get for free. This is what they think:
Make each feature work hard to be implemented. Make each feature prove itself and show that it’s a survivor. It’s like “Fight Club.” You should only consider features if they’re willing to stand on the porch for three days waiting to be let in. That’s why you start with no. Every new feature request that comes to us – or from us – meets a no. We listen but don’t act. The initial response is “not now.” If a request for a feature keeps coming back, that’s when we know it’s time to take a deeper look. Then, and only then, do we start considering the feature for real.