Recently, at MonitorBase.com, as the [title goes here], I've made the decision that we are ditching the backlog. Let's go over my reasoning along with the rules.

The Problems

With many IT teams, the number of tickets coming in far exceeds the ability of teams to keep the number of open tickets stable. As time continues for a given project, the number of tickets in the backlog keeps growing and growing. As the number increases the amount of time it takes to manage the backlog and decide what should be inserted into the sprint starts increasing exponentially with each passing month.

Beyond the time factor, the mental impact of an ever-increasing amount of tickets and the inability to have an effective burndown rate can make it appear that the team isn't working hard enough. Any good IT manager or PM knows that the number of tickets closed in a given timeframe is a horrible KPI for IT teams, but upper managers will keep asking for this to be included in the performance of a team.

We've all seen what backlogs become: a dumping ground for half-baked feature requests, edge case bugs that appear once, and well-intentioned fixes that will never happen. So, how do we address these issues, increase the team's focus time and still provide understandable KPIs to upper management?

Solution

It's pretty simple. Allow the entire team to be able to create tickets, like always, but auto-close any ticket that hasn't been updated in 90 days and attach a "stale" label. Another option I’ve seen proposed is closing based on created date, but I don’t believe that is the correct approach. If a ticket is being actively discussed and contemplated, it deserves to stick around until it can be brought into the sprint/cycle. If a ticket is created and then it's radio silence after 90 days, it's safe to assume that ticket won’t be making it into the sprint.

But, what if a project owner or client actually really wants one of those now auto-closed tickets completed?? Simply reopen the ticket. This will restart the 90 days of updates. Eventually, the team can see that a ticket keeps getting closed and then reopen. When this occurs, it's time for all owners to discuss the merits of the ticket and if it needs to be actioned against or put to rest.

Drawbacks

I’ve just implemented this process with my team recently, and it will take several cycles to identify any unanticipated challenges. I’ll report back if and when those items arise. However, I don't think there will be much of a drawback or pushback. If a ticket is closed, the creator or project manner can just click reopen, which will lead to trackable decisions about the importance of that ticket.

There is no loss of data, thoughts, or discussions. All that information can quickly be found in the closed tickets and searching for the stale label.

Rules

• Close any ticket not updated in 90 days
• Tickets can be reopen
• After 2nd closing a discussion on the merits

Thanks, for reading, please let me know if you found this helpful or have questions over on Twitter: twitter.com/DigiGuyDev or in the comments below!