It’s obvious that your R&D team can’t do everything at once, right?

It’s obvious that items lower on the backlog aren’t going to happen unless they displace something higher on the backlog, right?

And yet. Lots of those items are people’s beloved ideas. Good ideas, that would make the product better, open new business opportunities, solve real problems. 

Good ideas are going to be rejected for a lack of capacity to develop and exploit them. This makes a lot of people sad, so product managers can fall into a trap. Instead of taking action, they ignore the backlog as it grows to thousands and thousands of items. And now, it’s no longer functional. Instead of a todo list, you have a swamp. People who actually need a backlog start doing their own in shadow IT, the roadmap moves into spreadsheets, and your organization no longer has visibility between planning and execution.

There’s a solution to this: Automatic bankruptcy. Any tickets that aren’t touched in six months get resolved “future consideration” with a friendly note to reopen if it’s still relevant.

Let’s look at how this works at each level of activity:

• Tasks are the easiest— a task is just a development note of things that ought to be done. When they don’t get done quickly, they’re forgotten. A reminder at six months lets the unimportant and already done tickets close easily, and prompts the developers to do it if it’s still important. There’s even an argument to silently close these, though I don’t agree with that idea.
• Bugs are also pretty easy. Bug tickets are regularly opened without sufficient information to act on, leading to either stopped communication or out-of-band investigation. This produces a steady flow of junk tickets. Real problems get fixed way before six months, if only because they hit some executive’s inbox. So a bug with six months of inactivity is highly unlikely to be acted on. Shut it down. Maybe the watchers will reopen with new information.
• Stories (may also be called Improvements or New Features) are where it gets tough: this is where you’re discussing people’s ideas and problems. Maybe the filer is losing hours per week because this story isn’t done. Maybe they’re going to lose some deals. Maybe they’re just insulted that you aren’t acting on their advice. Nevertheless, six months of inactivity is a strong signal: your team has not had bandwidth for this. Don’t delay any further: it’s the Product Manager’s job to determine if this is truly a priority and make it happen, or to let the filer down as easily as possible. A PM who avoids this difficult conversation is doing no favors to anyone.
• Epics are easy, just collections of stories and bugs, everyone forgets they exist as soon as MVP is shipped. This is housekeeping on the same level as tasks.
• Initiatives: now for the hardest one. Initiatives may not be in the same backlog at all, maybe you’re using post-its or a spreadsheet or a product management specific tool. Still, you’re looking at the same problem as the story, just writ large. Should we field a product to enter that market? Maybe it’s a good idea, that’s great. But, there’s other things that won’t be done now, and the point of this process is to include opportunity costs in decision making. Or maybe there’s been some out-of-band people working the idea to prove it out. If customers don’t really want it or you can’t really build it, then it stops. Lots of initiatives quietly die, either untried or stopped after investigation. Just like in the development backlog, they clog up your vision, until you no longer know what your plan is. As a product leader, if you’re trying to tell the e-staff and board that there’s ten years of work in your todo list, expect to hear some questions.

It really doesn’t matter if we’re discussing board-facing initiatives or developer-facing tasks or the stories and bugs between them. After six months of inactivity: everything must either die or be defended.

Doing it in Jira:

1. Meet with R&D and customer support leadership so they know what you’re about to do and why you’re doing it. Get at least to disagree and commit. It’s critical to note that resolution isn’t permanent — if the team is willing to keep reopening this ticket, maybe you need to just do it. The goal is to make communication happen.
2. Edit the relevant shared schemas and add a resolution type of “Future Consideration”. For instance, you might have four schemas: initiatives, software projects, SaaS projects, and services projects. Make sure all software development projects use the same schema or else life sucks too much for you to follow any of this advice.
3. Announce to the organization that you’re starting this process.
4. Make a saved search like this: updatedDate <= startofday(-180d) and resolution=unresolved. You’ll probably need to start with a selection of projects and gradually expand to everything as you train the organization to this new reality.
5. Schedule it for once a week on your most communication friendly day.
6. Bulk action, Transition, Resolve, Future Consideration, Resolution Comment: “Automatically resolved after six months of inactivity. Please reopen if still valid.”
   • You’ll want a keyboard shortcut for that phrase, just like “What is the problem you are trying to solve?”
7. Leave the Send Email button checked on, and politely engage with the conversations that result. 

relevant link from Matt Schellhas