I'm new to Jira and Greenhopper in particular. When I "Create an Issue" for Type I see four Issue Types: Bug, Enhancement, Epic, Task. If I create an Epic I can add Stories as "children". Under Stories I can add Sub-tasks. I can find docs about Sub-tasks but there is hardly any mention of Task issue types.
How are Tasks to be used and how do they relate/differ from Sub-tasks? In my thinking I would picture the hierarchy as Epic / Story / Task / Sub-task but apparently that isn't what is intended here. From what I can tell it's Epic / Story / Sub-task or Epic / Task. Is that correct? If so, what is the intended use case and differences for when to use these?
Given that Stories are non-technical issues and Epics are groups of Stories, where are you supposed to put technical descriptions of what you plan to do to resolve the issue and provide a way to further break that down into sub-tasks?
Given that our team likes to assign and track effort and time, we have found Sub-tasks don't allow assigning effort points nor does it show anywhere except on the Story they are based on (the parent). You can't see them in the Backlog. You have to view the Story or search for them to find them.
What is the expected methodology to use?
It's like this:
Level 1 - Epic
Level 2 - Enhancement/Task/Story - In fact this can be anything based on the issue types in JIRA. These are just the default ones
Level 3 - Sub-tasks
It just follows the same terminology and practices in Scrum. Till the story has not matured enough to be broken down as technical tasks, keep addiing all information in the Story itself. This keeps it simple.
Thanks for the explanation!
We suffer from team confusion around what goes in an epic vs story and how to relate that to tasks (which are fairly self-explanitory). We generally or intuitively want to place Tasks under Stories which are non-technical generally. So Tasks are done to implement the solution for the Story. Epics seem to be a higher level "folder" of stories with a description at a higher level of abstraction.
I suppose we will continue to wrestle with how to make this work for us.
I agree with @Victor Grazi - There are 3 levels in JIRA, but use of JIRA in a Scrum fashion really uses 4 "levels": Level 1 - Epic (Issue type in JIRA), Level 2 - Story (Issue type in JIRA), Level 3 - New Feature/Improvement/Bug/Task (Issue type in JIRA), Level 4 - Sub-task (sub-task type in JIRA)
The problem with the current categorization in Jira is this : Normally in Scrum you do define tasks for (user) stories which then are tracked by a simple two level tree logic. There is the (user) story which is represented by the Product Owner and there some tasks which are worked on by the Scrum Team for that (user) story. When you try to visualize this in Jira you are confused by a new term of "Sub-tasks" for (user) stories because tasks are created at the same level with (user) stories. To bind tasks to the (user) stories you have to create separate relations from tasks to the (user) stories and yet they aren't shown on the issue list one level under the (user) stories. They are shown to be at the same level with them. You can't visualize the (user) story - task grouping (to my knowledge at least). If you use the sub-tasks in place of tasks because they can be shown to be one level under the (user) stories then you lose the ability to track task-(user) story completion and relation status.
There are dfferent methodologies and different useage scenarios.
that's why software must be flexible and not rigid. Admins should be able to define levels of hierarchisations. A subtask is by definition the child of a task and do not need to be followed by PM. Tasks linked to stories are most often sections of stories or different stages of implementations.
So what we need to is a flexible 4-level hierarchisation. Epic-Story-task-subtask.
Why does something so logical is not implemented? why limit and bottleneck us and fight against how people may use?
SOFTWARE MUST BE FLEXIBLE!
Given our team's dislike for Sub-tasks for the above mentioned reasons, we essentially have Epic / Story or Epic / Task. That seems limiting given Stories are non-technical requirements. Where can you break down the Story to design and implement a solution for the Story requirement(s)?
Yes, there is hierarchy in JIRA, but in general there is not "unlimited" hierarchy. I can't speak for Atlassian, but limiting endless hierarchial levels allows users to focus on other ways to organize issues. There are many tools in JIRA's toolbox with which to organize issues, and after doing some strategy, I've never had a client unable to find a good solution.
And if you truly need unlimited hierarchies in JIRA, we can make that work too, although that's not my preferred method.
Yes, WHY limit a free 'tree' hierarchy? I find it to be the most useful feature when I need the flexbility to organize anything (tasks, requirements, anything)
I think it is not available because it poses UI challenges, because, conceptually, it makes all the sense not to have sucha a limitation.
@Justin, in which way(s) can that be made to work?
it really should be Epic/Stories/tasks. Epic and stories are related but have a hierarchy. Tasks are the actual units of work to be tracked. If you think sub-tasks are part of a task, from a Scrum standpoint, that doesn't make sense because you shouldn't have to break a task into sub-tasks. If you think you need to, then your perception of a task is not correct and it needs to be broken into simpler tasks. From JIRA's standpoint it seems that a task is something else.
I am new to JIRA so excuse my ignorance, but...
Along Bruce's line of thinking. Our department uses Epic / Story / Subtask. The problem with this is that disruptive tasks are a very common occurrence and need to be included / connected to the subtask. But Issues/Tasks cannot be connected to Subtasks.
We are considering the Epic / Story / Task / Subtask path. Take into account we are using the JIRA email auto creation to create Issues/Tasks that after the fact will be including in the above workflow. The email created Issues/Tasks will be converted to a Subtask to flow under the task. Will this work?
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot