Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage
  • Community
  • Products
  • Jira
  • Questions
  • Best practice for postponing issue indefinitely, i.e. "good idea, but we'll look at this again some time the future"

Best practice for postponing issue indefinitely, i.e. "good idea, but we'll look at this again some time the future"

We commonly have issue submissions from our developers or applications engineers for new features (big or small) or feature enhancements that, for one reason or another, we don't plan on working on for a long time. These are things where your reaction is "yeah, that's a good idea, but we won't have time to work on that any time soon".

People like keeping the issues in the system because we may want to do them at a future date.

In our previous issue management system (before switching to JIRA) we used an issue type called 'continuous improvement'. We periodically review all 'continuous improvement' issues to see if they should graduate into real features or bugs and therefore get scheduled and worked on.

Now that we are switching to JIRA I'd like to hear any opinions on the right way to handle these types of issues.

Part of my goal is to keep the issues in the system so that (1) we may find them and work on them later and (2) people don't submit duplicates. However I don't want managers and developers to be burdened with sifting through hundreds of these issues to find the important ones we plan on working on.

Some of my current thoughts:

  • Rather than a special issue type (continuous improvement) we will add a new issue state called "Deferred". We will periodically review all Deferred issues. Our Kanban boards will not show any Deferred issues.
  • We could reject any issues that we don't see ourselves working on in the foreseeable future (the next several major releases). (this is not a popular idea).



6 answers

1 accepted

1 vote
Answer accepted

Documenting what we did, just so I can 'accept' an answer. In our workflow we are using a Deferred issue state. 

Hi Nathan

Have you thought about using a label instead of a new Issue State? I often categorise Issues with labels; Draft, Ready, Customer, and Deferred. 

Labels are pretty Flexible and you can change your Kanban board JQL filter to exclude any issues with the label "Deferred". Alternatively you could create a quick filter or swimlane to your board to separate them.

I've blogged about using labels and quick filters for Sprint Planning if you want to adapt it.


That's a fair suggestion, I'll think about it. Off the top of my head, my concern is that labels don't visually stand out enough, and managers / developers may accidentally spend time looking at an issue with a Deferred label. That could be fixed via filters as you pointed out. Thanks.

Close with a resolution of Not Yet. Close implies you're not going to work on it. The resolution lets you find them to review them. I know this is unlikely to be

popular but it is truthful!

This is not an answer. But how can I even ask a question? Where is the link for that?

I find it rather frustrating that there is no real documentation in this JIRA tool. Something with a table of contents, like a normal manual.

When I go to the "resolve issue" form and click on the "?" next to "Resolution", a new page comes up and it lists a status called "POSTPONED". How do I enter this status?


The challenge is that the "wish list" continues to grow unbounded over time, and its hard to separate "good ideas" from noise. We use a separate project to track these in, but it is often not up-to-date. Similar to Pivotal's Ice Box

You can consider making 2 'releases'. 'Future' for issues that are deferred to future releases on the product. 'Icebox' for issues that are deferred indefinitely. When you working on the next iteration of the product, create a new release (e.g., 2.0.0) and you can search for all the issues in 'Future' and 'Icebox' and triage to see if they should go into the next release (i.e., 2.0.0). I have used this previously and kept everything pretty clean. 

Suggest an answer

Log in or Sign up to answer

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you