What steps will reproduce the issue?
- Create an Epic
- Create 20 child stories on that Epic (the place where this is done, not the normal create normal for discrete smaller tasks).
- Now sort those 20 child stories in the order they need to be worked (impossible).
- 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?
- 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
- 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
- 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.
- 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.
- 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.
