Hello,
I've read several posts about this request and I couldn't find one that wasn't closed for comments.
Why would you restrict a very common request?
How can you assess the volume and validity of this request by forcing users to multiply the same request on many posts instead of keeping the existing ones opened. As a ticket manager, I know that there's nothing worse than having tons of cloned tickets.
Going into the details of the request, I need to react to the most common community leader answer.
The agile dogma is apparently against this practice, but maybe because it's more software oriented rather than production.
In production/dev teams, user stories might be used differently than what Jira envisioned but it doesn't mean that it's not a valid request.
For me epic is a group of user stories, and can span multiple sprints. User stories are feature related, and subtask are individuals assignable/estimable atoms of this feature.
User stories stand for objects, Tasks stand for unsplitable actions.
The issue lies in the definition of user stories. For some context, US should be done within a single sprint and prioritized at this level, in some other context, user stories can span multiple sprints and consist of several tasks that are estimated and assigned by/to multiple people and each of them need to be prioritized individually on the backlog page or even multiple backlog pages in the case of one backlog per team.
The alternative is to create independent tasks and link them with the user story.
The best would be to have the simple to setup possibility to have those subtasks appear in the backlog screen and have the user story being updated with the estimate and status of each subtask.
the example of this need is :
An epic is a campaign
The user stories are individual parts of it
Each user story needs several tasks, assigned to different people (design, webmasters, developers) and they need to individually be part of different sprints (one sprint per team) but the managers need a ways to easily handle/monitor those subtasks as well as the parent user stories that are part of a long schedule (many sprints)
Subtask, by its name and guessed meaning looks adapted to this need but appear to not work at all like the users expect. I haven't designed a workflow with linked task yet, maybe they are the solutions but the current subtask behavior seems counter intuitive and useless in many cases.
Maybe thousands of people want subtasks that behave the way I presented so I think that Jira's team should consider seriously this addition and show some respect to their users instead of telling them they are wrong and pushing back. I know that in software development you need to refuse some crazy requests that are out of scope or not feasible, but in this case I fail to imagine why it would be categorized this way. Jira is not a bible of methodology, it's a tool.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.