Epic Child Tasks Sorted Randomly (At Worst) or Arbitrarily in the Order Entered (At Best

[Wp]

What steps will reproduce the issue?

1. Create an Epic
2. Create 20 child stories on that Epic (the place where this is done, not the normal create normal for discrete smaller tasks).
3. Now sort those 20 child stories in the order they need to be worked (impossible).
4. Consider, if I realize scope was missed and it needs to be worked in the middle of the epic, I can only add it to the end of the epic

What happens?

1. Until This Week: They will be sorted in the order you entered then, which requires the planner of the Epic to NOT use Jira to plan the Epic only to document the initial plan there after it is developed externally. However, If scope changes, the Epic has to be rebuilt from scratch to properly sequence the linear view of the Epic Children specifically. This has been a nightmare pain in the butt for almost a decade with atlassian software. There are multiple tickets over the years requesting that this be fixed with high priority. One ticket attempted to fix it with hacky quick fix that did not even come close to meeting the original requested scope, the original request, that is closed, from years ago is still receiving votes (thousands already) as is the newer ticket (by newer, I still mean years old). This is very troublesome... the people responsible for building the software for managing our tickets and planning our projects are not able to do the same thing using another iteration of their
   • JRACLOUD-76877
   • JRACLOUD-40929
2. As of This Week: They are now sorted randomly... everytime a developer goes to the epic, they pick the next one in the list... now they are picking tickets at random and we have a sprint that has been a complete waste of time.

What is the expected result?

Order of preference implied

1. The Epic Planner is allowed to sort Epic children manually, in the exact same way that the Story Planner is allowed to sort Story subtasks manually.
2. Put it back the way it was so it sorts by key, so at least we can have the initial sequence of tickets (necessary to complete the epic optimally) correct, for the epic view of the data.
3. Reopen the original request from 3 years go, find another solution that provides the necessary and standard functionality that was requested and ensure it is implemented consistently for all child and sub issues for all ticket types

Requesters of solution 1 have been told not to use the Epic view for working the children, they have suggested creating a board where the children can be resorted; this is not an acceptable solution, nor is it valid architecture philosophy... data must appear the same regardless of graphics or location, idempotent programming is required even when it is not necessary... again very scary you guys are in charge of the software that manages our ticketing system and you don't know this).

Justification for solution 1 (HIGH PRIORITY ESCALATED)

• 1 ticket received almost 2000 votes, another almost 1000
• This has been a nightmare for a decade for me and my teams, across about 5 companies I worked for.
• It makes project planning 2-3 times slower
• It makes the software incapable of handling scope change on epics
• It creates an environment were tasks are worked in random order, resulting in rework and inefficieny.
• The original ask ticket is 3 years old and the user was ignored in the solution implement. We have been trying to get you to reopen it, but no one is listening to us, so it stays in closed state.
• The current ask ticket which is still "gathering interest" is over 3 years old.

if atlassian needs 3 years to (1) implement the wrong solution (2) ignore the requests to reopen and (3) ignore the second request... then this company isn't going to be around much longer... considering its your job to write software that allows us/you to do this not in a 3 year timespan, ours requires 24 hour response times for all ticket feature requests, bug reports or just a ticket comment. Atlassian needs to set a reasonable standard, 3 years of ignoring issues is not a good example to set, nor is it a good demo of ticket management for sales purposes. In short, this is ridiculous.

[saral · Accepted solution]

I don't have an answer, but I fully support your issue here. Not being able to manually drag and drop my Stories inside of my Epic makes life so much harder than it needs to be. 

[Wp]

agreed... they need to resolve this... they implemented sort instead which is effectively useless for this view of the data.

[Wp]

related: https://community.atlassian.com/t5/Jira-Software-questions/New-Bugs-in-software/qaq-p/2594905#M917439

[Gordon]

In the top right corner there's an Order By button. By default it uses rank to sort the issues. You can set the rank by dragging and dropping Epic child issues in the Jira Board Timeline view, the Backlog view or the Active Sprint view (most useful when using Epics as swimlanes).

[Peter Flynn]

Unfortunately Jira Server doesn't seem to have that Order By button. In the corner there's just a "+" to add new issues to the Epic.

But it does appear that in Jira Server, even though you can't change the sort order, the default/only order you get is sorted by rank.  You can't drag-drop to reorder the items from the Epic view (unlike with subtasks), but if you go to the Backlog and find all the issues there, you can reorder them there and I think the new order should be reflected next time you view the Epic too...

[Wp]

Order by is inadequate. It needs to be manual just like subtasks on a ticket... the amount of time our team is wasting due to these inefficiencies and inconsistencies isn't okay... if rank is what you are setting when you drag and drop a subtask on a story, rank is what should be set when you drag a child story on an epic.

As far as I am aware, we do not have the concept of 'rank' visible in our setup... but I expect the software to be smart enough to show tasks sequenced in the correct order... no matter where the list appears in the view layer.

[Gordon]

I agree that it should be possible adjust an issue's rank by dragging and dropping a child issue in the list on the Epic issue page.

With regards to the original poster's workflow of creating an Epic and then all its child stories and then re-ordering the child stories: you can do all of this in the Board Timeline view.

[Wp]

FYI - the reason the sort feature was implemented in the epic, is that there was a ticket requesting the ability to manually sort child issues in epics in the same way we can subtasks in stories (received about 4k votes across 2 tickets), and for an unknown reason Atlassian decided to implement sort for epic children instead, while not implementing it for subtasks in stories, creating an insane asymmetry in things that are inherently symmetrical in nature assume rank is the the intended default sort order for both as it would appear (no one on any team I have been on has ever knowing used the rank field... make it more obvious so these bug request resolutions become more obvious).

• Tickets proving this is true
  • JRACLOUD-76877
  • JRACLOUD-40929
• Issues proving the sort was quick fix that actually made the situation significantly worse. Terrible programming: if the default sort order is rank: (1) why is rank not even listed as an option (2) why isn't the dropdown defaulting its value to rank. (3) why isn't the rank (number I presume) listed with each row (4) why is it impossible to set rank from the list view herein and the ticket itself... I plan epics, not sprints that is someone else's job, so any type of board view your suggestion would require 1 board per epic which is insaine. Can you please escalate the multiple tickets requesting that this interface be repaired for standard functionality...

[Gordon]

It's kinda dumb but Rank is an "invisible" default. If you change the Order By to something else, only then is Rank shown as an option:

As for why the Rank number isn't shown, I would assume that it's because the actual number is irrelevant because it's adjusted automatically as you drag-and-drop items.

You don't need a board per epic. Your scrum board needs to use a query that includes all epics, stories, etc. for your project. In the Board Timeline view you can see a list of the epics and click the expander icon on the left to show the list of child issues for each epic. You can then drag-and-drop the child issues within that list. You can even create epics and child issues from this view at a specific position in the list by hovering your mouse in between two epics or child issues.