Return to Answer

minor typos, grammar and formatting

edit approved Oct 24, 2014 at 5:50

1.4k
10
19

Using hierarchy like Epic Epic -> Story/TaskStory/Task -> SubTaskSubTask works great with few exceptions:

There is notno way in JIRA to plan which SubTaskSubTask the team committed to finish in the single Sprint
If Story/Taskthe Story/Task is BIG then 1 level of decomposition could be not enough
In this way both Story and Task serve the same purpose and are interchangeable.

We go with dippera deeper hierarchy: Epic Epic -> Story Story -> Task Task -> Task Task -> ...
Here StoryStory is short for User Story, capturing requirements and own by Product. Task on another hand is the result of decomposition of the Story or another big Task and own by Development.

The only problem in this case is that naturally GH doesn't offer a way to define relationship between StoryStory and TasksTasks. We are using Parent Parent -- ChildChild link, it needneeds to be maintained manually.

I saw a 3rd party plug-in defining hierarchical relationship between issues and reporting on consolidated fro ChildrenChildren to ParentParent estimates and spendspent time. I didn't use it, so won't mention it here for now.

Using hierarchy like Epic -> Story/Task -> SubTask works great with few exceptions:

There is not way in JIRA to plan which SubTask team committed to finish in the single Sprint
If Story/Task is BIG then 1 level of decomposition could be not enough
In this way both Story and Task serve the same purpose and are interchangeable.

We go with dipper hierarchy: Epic -> Story -> Task -> Task -> ... Here Story is short for User Story, capturing requirements and own by Product. Task on another hand is the result of decomposition of the Story or another big Task and own by Development.

The only problem in this case is that naturally GH doesn't offer way to define relationship between Story and Tasks. We are using Parent -- Child link, it need to be maintained manually.

I saw 3rd party plug-in defining hierarchical relationship between issues and reporting on consolidated fro Children to Parent estimates and spend time. I didn't use it, so won't mention it here for now.

Using hierarchy like Epic -> Story/Task -> SubTask works great with few exceptions:

There is no way in JIRA to plan which SubTask the team committed to finish in the single Sprint
If the Story/Task is BIG then 1 level of decomposition could be not enough
In this way both Story and Task serve the same purpose and are interchangeable.

We go with a deeper hierarchy: Epic -> Story -> Task -> Task -> ...
Here Story is short for User Story, capturing requirements and own by Product. Task on another hand is the result of decomposition of the Story or another big Task and own by Development.

The only problem in this case is that naturally GH doesn't offer a way to define relationship between Story and Tasks. We are using Parent -- Child link, it needs to be maintained manually.

I saw a 3rd party plug-in defining hierarchical relationship between issues and reporting on consolidated Children to Parent estimates and spent time. I didn't use it, so won't mention it here for now.

Source Link

answered Oct 24, 2014 at 2:45

user153932

Using hierarchy like Epic -> Story/Task -> SubTask works great with few exceptions:

There is not way in JIRA to plan which SubTask team committed to finish in the single Sprint
If Story/Task is BIG then 1 level of decomposition could be not enough
In this way both Story and Task serve the same purpose and are interchangeable.

The only problem in this case is that naturally GH doesn't offer way to define relationship between Story and Tasks. We are using Parent -- Child link, it need to be maintained manually.