As I sit here helping another team clean up their backlog, I am wondering what others do in other organisations to keep their backlogs manageable.
For us, any ticket that is older than six months is reviewed.
If we think it’s not so important anymore (i.e. no customers reported it, no additional comments on the ticket etc), we close it knowing that if it was really important, someone will report it again or let us know.
If we believe it needs to be fixed, we attempt to resolve the issue within the next two sprints. If we haven’t fixed it by then, we close it because it probably wasn’t that important anyway.
So as part of our KPI’s we have a metric on an aged back log i.e. anything over 3 months. So you can see evidence if the backlog is being reduced, maintained or growing out of control. Its a very powerful graphic.
The difficultly is the players in the team with different perspectives on the backlog, as they don’t always align. Product Managers, Developers, Testers and Customer Success even have the tickets they directly manage and can often raise aspirational placeholder tickets so they don’t forget their ideas. What the KPI does is act as a catalyst for discussion, e.g. “So its been 3 months are we really going to fix this? Is there anyone that feels strongly this should be planned in to a sprint?” or “This story placeholder has sat here now for 5 months? As much as it may be great idea, have you got any evidence its commercially viable? If not, when are you likely to get it ?”
I’ve yet to see a project with clean backlog, there is always something to fix and improve.
We tried to do it many times, even added a rule that increases card priority based on how long it has been there (old cards get a bump in priority after every X days), but in the end there is always too much work and not enough availability.
The only way to clean it is to just archive/reject low priority bugs and fix only those with bigger impact.
Yes, my teams have a policy that anything that hasn’t been updated in 3 months gets auto closed. When I took over a new team, we’d do a few sessions of backlog review, and cull everything that wasn’t on the roadmap - few things are more demotivating than “some day maybe” tickets that never get actioned, so we closed those.
Am definitely a fan of auto-close. I once tried to work my team towards a zero bugs style of working where we regularly cull bugs that we cannot hope to address by having a montly clear-out. It requires small bites initially, because, that’s how you eat an elephant.
Am not a fan of any KPI things, they just allow gamification to start taking up headspace in your team. Auto-close feels like a good idea.
The problem I see with auto close, no-one is responsible for it. Who learns to ensure more valuable tickets are raised? Who takes responsibility for choosing to not do the ticket? How do we improve the effectiveness of the planning?
Auto closing will prevent people from raising tickets in the first place, especially if they’ve been burned by having them auto closed.
I guess, a bit like the failed attempt my team had to implement a Zero Bug Policy: The Myths And The Reality | Ministry of Testing . Is that by playing devil’s advocate, you find ways to reduce technical debt over having visible backlog that hangs over you. Having a “auto-close” backlog, is in my mind an urgency driver to focus minds on only doing “work” that delivers in the current quarter. Which makes things very context sensitive. If your team is doing long lead work, then zero-bug and auto-close are obviously not helpful.
In much the same way that Stephan Johansen explains contexts where zero bug policy does and not work, an auto-close backlog either sharpens the mind, it perhaps pushes the job back, upwards in the food chain to the project manager. In my experience, when you let developers sit on a feature for too long, it creeps on you. You also start to incur the debts of marketplace and environment rates of change. Something which to me indicates that long backlogs are fine for new products, but are no good for “utility” products.
/edit
I’m adding this one thought that motivates my experience around different strokes for different folks. It’s called Wardley Maps. I have this picture in my mind of someone on the oregon trail. There is a highway now, but when the race for America’s west coast started, scouts had a very different approach and used different landmarks to help them get people from Europe and the East-coast to the West coast. Today we do things differently, on roads. Roads are like amazon cloud, but scouts existed long before Azure and Google ever did. Time and scale matter a lot, scouts are good, but only for some jobs, threy suck at other jobs. Enjoy this video clip https://www.youtube.com/watch?v=L3wgzl2iUR4
Just to pick up one thing - I largely agree with what you write, except that long backlogs are fine for new products. That is particularly where you don’t want a long backlog - something you thought would be a cool feature may be entirely outdated in 3 months because the product pivoted to find market fit.
Generally speaking, it’s all about delivering value now and not hanging on to stuff that doesn’t move the needle for the business.
I get what you mean, but this isn’t about avoiding responsibility. We’re not closing tickets because they were bad ideas. We’re closing them because old tickets lose context and rarely reflect what’s still valuable to the business.
If something really matters, it will show up again through users, metrics, or day-to-day work. The backlog should be a list of what’s important now, not a museum of old ideas. Auto-closing helps keep it that way and keeps the team focused on current priorities.
Thank you all for your replies! It is great to see others doing the same thing. We don’t auto close….yet …… but I might start floating the idea and see what others may think.
Thanks for responding @kato and @conrad.braam , it’s why I love opening up alternative views to mine, so I can explore them a bit . There’s a truth we’re all searching for
I like the concept of the auto close focusing the mind, so I can see auto close working, but only if everyone buys into it. With the clock ticking, the strong advocates of tickets will campaign for increasing the priority to get them done and I can see the tickets that no-one cares about being left to the axe.
Where I am right now, our biggest problem with achieving that is that our Product Managers don’t manage their backlogs (in fact they even invented the concept of an Ice Box backlog! Something we’re totally opposed to). So we try to influence them by shining a light on their backlog problem so they take responsibility for it.
I added to my post a good YT link Gary, I could not find the damn link yesterday And yes, I do agree, auto-close is “largely” bad, but I hate KPI’s more. So being very clear in teams where our boundaries lie, being able to articulate clearly why those boundaries are there, (boundaries are good) and how we feel friction in the business can help us and also hinder us. All these things must be communicated before we act. Nothing creates friction against change quite like managers who have no ability to explain their thinking in words. …To engineers who are also unable to explain their reasons.
Cheers I’ve bookmarked both of those so I can read them later. One for you, I mentioned the bug flow at work that @j19sch mentioned in his talk . Whilst it was to some degree funny, it was something I could put in front of leaders to shake the tree a bit which is along the auto close route.
Totally get your view on the KPI’s and I know @kato has been all over that subject. For me I’m a stats nut so I can get pulled into that quagmire very easily I confess.
In short if a KPI doesn’t influence action to improve, it ain’t a KPI. That KPI we have on the aged backlog, is bringing the problem to senior leaders and is making them question why teams are not managing their backlogs. Thanks to that we can open up discussions on solutions that “focus the mind” - auto close now being one of them. But to me its vital that Product take responsibility first and acknowledge their problem. Without that, I know they’ll go to an auto closed ticket, clone it and stick it back in the backlog.
…… but I might start floating the idea and see what others may think.
. There’s a truth we’re all searching for 
And yes, I do agree, auto-close is “largely” bad, but I hate KPI’s more. So being very clear in teams where our boundaries lie, being able to articulate clearly why those boundaries are there, (boundaries are good) and how we feel friction in the business can help us and also hinder us. All these things must be communicated before we act. Nothing creates friction against change quite like managers who have no ability to explain their thinking in words. …To engineers who are also unable to explain their reasons.