In my 20+ years of software, I’ve always had a backlog for software development. The list is full of ideas, customer requests, and defects. It fills faster than the team can implement and some items become aged and never resolved. I’ve come to realize that if I don’t have a list with aged items it’s probably because I don’t have an open channel of incoming ideas and I’m no listening to my customers.
I used to stress over an overflowing backlog and it was a source of frustration. As I matured a bit with software development I realized it’s not realistic to completely solve the backlog queue. But it is realistic to improve processes to resolve the backlog items more efficiently. It’s not about an empty list but about what’s in the list and how the team is processing it.
After time, the priority of some backlog requests changes.
It’s like that shining new thing you want to buy. If you wait a week before making an impulse decision you often realize that you don’t really need that thing. Software is the same way. With the passing of time, some requests may no longer be relevant, or become less important as the business environment changes.
To keep the backlog manageable purge items periodically.
One inefficient process that I’ve found myself in over the years is continually prioritizing some backlog items that never get implemented. It’s the equivalent of re-work because the team rehashes the backlog item each time. Some backlog items are complicated and can take time to go over the relevant facts to determine a priority. At some point, the team needs to decide if the item should be returned to the backlog or purged.
Some possible purging methods:
- Time based – After a certain time period in the backlog an item is removed.
- No longer relevant – If the business purpose of the idea is no longer relevant.
- Revenue expectations – If the backlog item does not meet a specified revenue threshold.
- Non essential – If the backlog item is not required for contractual obligations or compliance of some external agent.
The backlog should be a primary input to your roadmap.
If I’m managing my backlog properly then I should see items removed and added regularly. A healthy backlog has both elimination of items and turnover. If I do this, then the items within the backlog list will be relevant to business needs and a primary input to the software roadmap.