Automatically closing your backlog tickets due to inactivity.
I remember my first encounter with stale-bot on GitHub. Shock and terror! I couldn’t understand why would anybody want to close the ticket I have just created not so long ago? “It is a real bug!“, I though to my self. “Why would anyone want to get rid of a genuine bug report”, I couldn’t shake off my bewilderment.
Today, after so many years being on the other side of the backlog, I can only laugh at the one sided view I have had back then.
For every developer who reports an issue, that might be one, or one of few issues that they are actually actively following. But on the other side of the backlog there is usually a development team or group of contributors that is way too small to be ever able to close all the reported issues in a realistic time. As a result the backlog keeps growing and growing, while the process of grooming and reviewing the backlog and keeping all the work items in it in the order of priority becomes harder and harder to complete.
Which raises the question: why keep all those inactive bug reports in the backlog? Especially that on the other side of this equation there are a lot of MAYBEs… Maybe some of those bugs have already been fixed by other work or refactorings? Maybe some of the issues are really extremely rare and don’t deserve the attention compared to other burning issues. Time has passed and the original reporter is not enquiring, maybe the issue or feature request is not relevant anymore…
Unless closing the issues in this fashion would impact the perception of your brand, I think this is a pretty reasonable approach to maintaining a crowdsourced backlog of issues and feature requests.
Having said that, I think this could be a very good vehicle for keeping a lean backlog even in an internal organisation. I believe it could apply in multiple scenarios. For example when there is a significant number of stakeholders that you are interfacing with. Or maybe you are encouraging each and every developer on your teams to keep reporting improvement ideas and issues directly into the bug tracking system. In any such case where the number of items in the backlog is growing faster than the speed at which you are able to solve them, this approach can help bubble up issues faster and most of all might help you find that subset of the issues “that just can’t be closed”.