In a company-managed project can we group the Backlog Items?

[Athas Mark]

Can the backlog view be configured to:

• Group the items by a category variable, such as Priority
• While still allowing moving the items within the category by drag-n-drop
• While also changing the priority if an item is moved from a one priority group to another [e.g., lowest to medium, highest to medium] high priority group (may require an automation event)

[Mykenna Cepek · Accepted solution]

Typically the Filter for a project is set to sort by Rank (which is recommended). This allows the drag-n-drop functionality to work in the Backlog view and on Scrum/Kanban boards.

Otherwise, no, the stock product does not offer a way to group items shown in the Backlog. However...

Quick Filters are commonly used to help segregate different types of issues. This is nice because it also tends to remove clutter on the board, allowing better focus on just the "group" of issues of immediate interest.

(One negative with Quick Filters is the same set of filters is used in the Backlog and on Scrum/Kanban boards in the Project. I've found different needs in those two views; YMMV.)

Another way to "categorize" (story-level) issues in the Backlog view is to use Epics. Attention to giving active Epics unique Epic Colors can help provide easy visual clues as to which "group" issues belong to.

[Bill Sheboy · Accepted solution]

Hi @Athas Mark 

Short answer: no, that is not possible with out-of-the-box Jira.

Longer answer:

The drag-and-drop ordering of a backlog works when the filter contains ORDER BY Rank ASC.  If you changed the order expression the drag-and-drop no longer functions.

A work-around for what you describe is to use quick filters by Priority to limit the view to just one category/priority at a time.  You would still need to edit issues to change the value of Priority.

Kind regards,
Bill

[Athas Mark]

I'm aligned,  Use Quick Filters--let the backlog view operate as-is.  Thanks !

[Jim Lile · Accepted solution]

technically your stack ranking (top to bottom) is your priority.  I have never heard of anyone organizing their board by a priority field (other than expedited) or other than in a "bug burn down" (aka bad practice).... I know with Kanban boards you can setup and "expedited" lane and if you add any item with that priority it shows up in the Top swimlane. I think you should move your stories in a "stack rank" in your sprint and move them as needed. This seems to be more overhead and not what the core of Jira is about. You might want to add priority to your view in the backlog

[Mathias Richter]

Hi Athas Mark,

just to make the list of options "more complete":

If you're using the Advanced Roadmap functionality you can group by different attributes of your data (but not priority). This groups your data by a specific selection, e.g. by Release or Label. 

One thought I had is, that you could use labels to kind of present a priority of an issue (this could e.g. also be automated by removing and adding the correct label based on the defined Priority). 

This way the grouping could be achieved, although I also have to comment (like the others), that Rank is already a priority by itself and using Rank and Priority is kind of "double-order". 

Regards
Mathias 

PS: Group issues on your Advanced Roadmaps timeline | Jira Software Cloud | Atlassian Support

[Johnny FromCanada]

Why are you trying “double-order” simultaneously?

[Athas Mark]

 Good point.  I shoulda stated my problem...  We have PO's that need to track two things.  Only the second is important for our team performance measures.  1) Track the list of all the things we think are possible for the product. 2) Track the list of things we have "committed to deliver"  These committed to prioritize items may still be very loosely understood (e.g., not refined).  It is when the PO commits to the customer that the team will deliver a functionality, that's when we start the "Lead Time" clock.  We don't want to start lead time when an issue is created.