Backlog management: don’t fear the reaper
The reaper in this case being the delete button
Our team has two main work streams:
- Features i.e. developing shiny new stuff
- Support i.e. supporting the legacy systems the shiny new stuff is going to replace
We’re lucky to have stakeholders that appreciate there is more value in developing new systems than just propping up old stuff. So we have an agreed maximum commitment of two developers per sprint on support.
In the average sprint two developers close eight support tickets, but twelve new tickets are opened. So without a management strategy (or more developers) the support backlog can never shrink.
If the support backlog was frozen today it would take approximately a year to clear, so the team has adopted an approach to limit the growth of the backlog and make prioritisation as easy as possible; we divide the backlog in to three parts:
- Top 5
- Overflow
- Death Row
Top 5:
Every Monday the PO and Tech Lead meet with a senior stakeholder in front of our backlog. This meeting is to select the Top 5 support tickets, and put them in priority order. These are the only support tickets that should be worked on. It can and does change when other issues are identified during the sprint, so we pretty much never clear it out.
This is the only planning that gets done on support, we don’t score tickets, and don’t plan forward into the next sprint because the work is so unpredictable. However, we do count the number of completed tickets at the end of every sprint, so we that have a rolling average of how many the team is likely to complete in 2 weeks.
Overflow:
Tickets not in the Top 5 are in the overflow:
This is the main body of the backlog, and it’s where the Top 5 come from. There is a separate section for tickets raised in the current sprint, as these are the most likely to get prioritised. The main benefit of the overflow is that it shows stakeholders just how much work there actually is, which encourages them to think carefully about what should be prioritised.
This is important, because most of the tickets in the overflow will never be done, but will instead end up on….
Death Row:
Tickets can only live in the overflow for 3 months, after that they are marked for deletion and sent to death row. Stakeholders have the opportunity to reprieve condemned tickets at the sprint review.
If no one wants to save it, it gets deleted.
If nobody in the meeting knows what the ticket is, it gets deleted.
It can be reprieved and go back to the overflow for 3 months; but if it doesn’t get worked in that time, it gets deleted.
Since we started doing this, more than a hundred tickets have been on death row and about a quarter have been reprieved. Of those, so far only one has been prioritised and completed.
We have had a couple of ‘Lazarus’ tickets that have been deleted and then raised again. For me this just proves that the system works, if you delete a ticket and it was important then the issue will come back organically.
So don’t fear the reaper, use the delete button. It’ll make managing your backlog a whole lot easier.
