As I’ve mentioned before, a key aspect of building quality software is ensuring that it does what the users need it to do. In my experience, the backlog of feature request (whether written or held in the stakeholders’ heads) is always much larger than what the development team can build in a short period of time.
When the backlog gets too big, people could spend more time managing the backlog than actually building anything. What is more likely, though, is that most of the backlog is ignored, and the clutter causes great ideas to get lost. I have seen cases where key customer issues ended up unaddressed for months until the customer complained a third or fourth time.
I sat down with one of my clients to look at their backlog, and we found that they had over 400 backlog items that had not even been viewed for more than a year. They had more new, high-priority work coming in than they could deliver, so their backlog was growing. Clearly, nobody was ever going to review, let alone work on, the items that were over a year old. I suggested simply closing the backlog items that hadn’t been touched for over a year, but the client didn’t want to remove any items from the backlog without first reviewing them in a meeting with a team of key people, which was not going to happen.
The discussion reminded me of an episode of Hoarders where they were trying to convince someone to sell most of his 27 tool boxes. He agreed that 27 might be overkill, but he still didn’t want to sell them and insisted that the average person, who wasn’t a handyman like him, would need at least 7 toolboxes.
When a backlog gets hopelessly large, you may want to consider declaring backlog bankruptcy (based on the concept of email bankruptcy) and simply close all items that haven’t been looked at in over a year. If that sounds scary, I can understand. I tend towards hoarding myself, and I hate the thought of getting rid of something that might come in handy later. If declaring backlog bankruptcy, it may help to keep these ideas in mind:
Once you cleaned up the backlog, you want to try to keep it manageable. It helps to have a weekly triage process where the items are reviewed and prioritized. Some decisions that should be made during the triage process are:
I’ve found that it’s easier to identify which issues to review if you create a report that shows the priority of each item, the date it was entered, and the date it was last reviewed. This type of report helps ensure that older items are addressed.
What challenges have you had with backlog clutter? What actions have you tried to address the challenges? I’d love to hear your stories from the trek.