I’ve noticed some development teams completely remove issues from their Jira backlog when they decide not to work on them anymore. This doesn’t seem right to me. I think we should keep these issues around for tracking purposes and historical records. What’s your take on this practice? Have you worked with teams that delete unused issues? I’m curious about different approaches teams use for handling backlog items they won’t be implementing. Maybe there are better ways to manage these unwanted tickets without losing the information completely.
depends on your team size and project scope. smaller teams can just delete stuff, but larger orgs need the paper trail. we use custom fields to mark items as ‘parked’ or ‘maybe later’ - keeps them in the backlog but filters em out of active work. super helpful when product owners change their minds (happens all the time lol)
Don’t delete issues completely - huge mistake. We tried this a few years ago and it backfired hard when stakeholders asked about old features months later. The audit trail was gone and nobody remembered why we’d rejected stuff. Way better approach: use a resolution status system. Mark things as “Won’t Do” or “Declined” with clear reasoning in comments, then close them. You keep the history but clean up your active sprints. Use filters to hide closed items from daily views - you can still pull them up when needed. Bottom line: business context and decision history are valuable. Don’t trash them just because you’re not building something right now.
We archive old issues instead of deleting them. Been doing this for three years and it balances keeping our backlog clean while saving institutional knowledge. We move declined items to a separate ‘Archive’ project in Jira with labels explaining why - budget issues, tech debt, shifting priorities, whatever. Unlike just closing issues, archived stuff doesn’t clutter your workspace but you can still search it later. This has saved us tons of times when leadership circles back to old ideas or new team members ask about features we already considered. Takes five minutes per sprint to archive properly, but the documentation payoff is huge.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.