-
Suggestion
-
Resolution: Unresolved
-
None
-
None
-
None
-
2
-
We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.
[JSWSERVER-15740] There needs to be an Icebox bucket that lives in the Agile view. All newly created issues should default to the Icebox. The backlog should only be for issues that are fully defined and ready to be worked on in a coming sprint.
would love to see this feature as well. One hack we have is to create a sprint called Ice-box, but this makes the issues show up above the backlog, which is visually confusing, as it contains lower priority items.
+1. I have an Epic called "Icebox" that I put things into in the meantime but having this built into the flow in a more intuitive way would be great.
+1 currently management treats "backlog" as "all tickets needing fixed" and has no concept of backlog, mixing "service desk" with "development" tickets which are not the same thing. All tickets are treated as first class citizens, aka metrics: must be responded to quickly, assigned quickly, closed out quickly, etc. This leaves no place for "ideas worth considering" or "long-term fix to improve overall quality" kinds of tickets - which are otherwise forgotten if not logged.
I like the icebox idea because it seems like it could fix this problem - although it probably means that all other boards & filters would need a (AND project not in (icebox)) added to them. – or however you end up implementing. My example uses a project, which could be done with current system – but doesn't allow for specific project-related ideas, so I think the icebox is still a good idea.
I'd love to get feedback from someone at Atlassian to see if this is on the roadmap. We are considering switching to a different product because this feature is missing, so it would be helpful to know if this enhancement is planned.
Yes please! It would be amazing being able to separate tasks that we might work on soon (next sprint, later in the update, etc) from tasks that we don't expect to work on for a while, but still want to keep track of (e.g. huge features that we can't priorities at the moment, very minor bugs and other low priority stuff).