Aware of how a backlog can get crud in it, we had planned to do a major cleanup over the New Year. However, tight project deadlines motivated us to push out the effort. By March I was fed up and decided to finally get it done, even if it cost us some time.
For this cleanup, we wanted to achieve two things:
- leave only work that we reasonably could get done this calendar year
- prioritize the work by value
Leave only work that we reasonably could get done this calendar year
I try to collect data, when is is possible to do it inexpensively. I had a good cumulative flow chart encompassing about 30 weeks of work. This gave us a good idea of the amount of work we could get through in the three quarters of 2019. Accounting for work that was not in the backlog at “day zero” (bugs, feature requests, infrastructure improvements) was less of a science.
We assumed that up front we knew about 50% of the work. If the number ended up lower, than we would find something to keep us busy. If it was much higher, any plans would be discarded anyways.
Prioritize the work by value
Here I have to admit to letting the tool put some restrictions on us. The tool we use to manage our backlog has four priorities, so we sorted the work items into five buckets:
- Work that we must do (40%) – failing to do this work would be catastrophic to the project. As we work very close to the hardware, we have a lot of requirements and restrictions that basically stem from physics
- Work that we should do (20%) – failing these would have serious negative consequences, but we could mitigate or live with them
- Work the we would like to do (35%) – the polish that we want to put on the product or internal infrastructure; here more than earlier the effort would determine, if we wanted to do the task
- Work that we shouldn’t do (5%) – this is work that in the opinion of the (majority) of the team shouldn’t be done, but we haven’t gotten full stakeholder (including the team in some cases) buy-in
- Items to remove from the backlog
The percentages indicated the backlog composition after the scrub. After we were done less than half of the backlog remained and remaining items could fit into this year’s bandwidth. Note that the category we chose was based on the our understanding of the value the day we did the review and may change.
The actual prioritization involved a long table with the five buckets marked with tape, a whole bunch of pizza (bribe), and a deck of story cards. I’d read out the title and the team would point were an story would land. Maybe 10% required discussion and it was usually to chose between two neighboring priorities. Though in a few cases we actually had a technical discussion. So I think it was a good exercise, even if I almost lost my voice at the end.
What got discarded
It was interesting to view, what we actually pruned from the backlog:
- Items that were already done – a detriment of a large backlog is that people will create a new work item for what they’re doing instead of using the one in the backlog (that they can’t find); it may also mean that the granularity of stories is off
- Items that no longer make sense I – this is items that were once valuable / strategic, but the environment has changed or the ROI is no longer there
- Items that no longer make sense II – bugs that got resolved through other fixes; features no one is asking for anymore etc.
- Good ideas that won’t see the light of day – there’s only so much time in the day and some good ideas (especially around internal tools and infrastructure) we’ll never be realized; it’s better to be honest with yourself and close them rather than repeating “one day”
- Work that no one will do – these are items that someone filed, because they didn’t want to do the work (at least right away) and no one will pick up, because they;re not attractive to pull (no external value, not fun to do). Common examples include refactoring needs that got notices while doing other work. Either you do it right away or you’ll never get it done.
How we benefited
Immediate benefits included bringing to light important work items that got lost in the shuffle. We were also able to reset expectations and show the direction for the year. In the week following the cleanup a number of easy items got quickly resolved – because they were fresh on everyone’s mind and didn’t require a lot of effort.
Long-term, this should make backlog grooming easier and selection of work items (we do Kanban) more intuitive and provide better value.
As a follow-up, I want to review the items (going by priority) in future backlog groomings to make sure we got the value right and that the stories are well-defined (I already see some opportunity for improvements).
Agile Musings 