Is Epic, Story, Sub-Task the recommended hierarchy?

[Aaron Ko]

I've looked around, however I have not found a clear answer to this. 

In my JIRA Agile Project (Scrum), I have an "Epic", then 2+ "Story" for 1 Epic.  We would estimate in the Story.  

Now developers need to break down the Story into actual development tasks.  

For 1 developer 'task':  

A)  Is the task a "Sub-Task" of the Story?   Story–>Dev Task 1,  Story–> Dev Task 2

B) OR is the task just a Task,New Feature,Improvement Issue Type, and I "link" with my Story?  

Our developers are using the GitHub-JIRA integration, for visibility of code commits in JIRA issues. 

I typically assign issue types like "New Feature", "Improvement", and "Bug" for items that are "code" related.  

My simple question, is the "dev" task a Sub-Task OR just "link" to the user Story? 

How does Atlassian manage their hierarchy for their Agile project?  

[Jim Constant]

Aaron,

A JIRA Story is broken down into Sub-tasks. When you do this, you can have the Sub-tasks appear under their parent Story on your sprint board. Depending on how you have your board configured, you have some estimation options as well. One of those options is to estimate Stories in points and the Sub-tasks in hours. JIRA will add up all the Sub-task hours to show you the total. You can then use Story points or Sub-task hours on your Sprint Burndown chart.

A Task is at the same level as a Story and, like a Story, it can be broken down into Sub-tasks. The difference is just semantic in order to distinguish between an issue that is actually a User Story and one that is just another thing that needs to be done. Which you choose is completely up to you.

Hope that helps.

[Aaron Ko]

Jim,

That re-enforces some of my assumptions, that "Sub-Task" is the only way we can create the relationship between Story and the actual "task" (or sub-task in this case) that the developer will work on.  Thus that "sub-task" will be the development item.  

In this case, that also means that I need to assign a "development" workflow to my "Sub-Task" Issue Type in my JIRA Agile Project.  

My concern, is that if I only have 1 Issue Type available to me (Sub-Task), I can only have 1 Workflow also.  In a typical development project, I may have "code" related items and "non-code" items, which may need a simpler workflow.   Does that mean I need to create a 2nd or 3rd "Sub-Task"-like Issue Type? 

I use several different workflows for generic task, development item, and bug/defect.  Thus, my current.  Thus my current challenge.  

Thanks,

Aaron

[Phill Fox]

Hi folks,

Be aware that you can define any issue types at the same level of story, task, etc (standard) and similarly at sub-task level. These you can give any name that is appropriate to your business context. Unless you put some effort in with your create transition and the use of extended functions you are reliant on your users choosing the right sort of subtask to match the parent. 

See more detail at https://confluence.atlassian.com/jiracloud/defining-issue-type-field-values-735940734.html#DefiningIssueTypeFieldValues-Creatinganissuetype

Hope this clarifies as well as extending the answer.

[Aaron Ko]

Yep, I was looking at that also today.  I think I've come to a conclusion. 

Below the User Story, I will always need 1+ Sub-Tasks.  

For Sub-Task, I may have 2 "types" of "Sub-Task"

1.  "Sub-Task" --> this is normal sub-task, will simple workflow (To-Do, In Progress, Done
2. "Sub-Task-DEV" (for example) --> this would be "software code" with more complicated workflow (To-Do, In Development, Code Review, In QA, DONE).  

After I click  "Create Sub-Task" (under More menu), I would have option of 2 different Issue Types. 

I think that's the only way I can get what I want (to manage both "code" and "non-code" task, each with it's own workflow).  

I just did it in my test JIRA instance.  

[Fei CHEN]

Aaron, I read you question while I look for documents about how to structure works with Epic, Story, Task, and Sub-Task.

Basically, Story refers to a piece of requirement which can be done within a single sprint, Task is a piece of technical works should be done within a single sprint by engineers.

Epic is a large body of work which contains a lot of stories and will be completed in multi sprints. Epic is parent level issue type of Story and Task.

Sub-Task is child level issue type of Story and Task, which is the work break down of Story and Task.

You may organize your work and information with this hierarchy. For more information you may refer to following documents:

1, https://wiki.onap.org/display/DW/Epic%2C+Story%2C+Task+and+Bugs

2, https://www.atlassian.com/agile/project-management/epics-stories-themes

3, https://www.atlassian.com/agile/tutorials/epics

4, https://pmcircle.wordpress.com/2015/07/30/confused-about-epic-story-task-and-sub-tasks/

5, https://pm.stackexchange.com/questions/16739/what-is-the-difference-between-epic-story-task

[eCPR]

Great question - I'd love some advice on this, too.
And if I could be rude and ask about estimation  / tracking - as a result of choosing sub-tasks ?

That is if you use sub-tasks - then you cannot provide an estimate of effort required for the sub-task.
So then (I assume) you  MUST use the parent story for estimation / work log entry?

Some documentation / workflow tutorial for Agile would be awesome!

Gavin. 

[Jim Constant]

Gavin,

You can provide hours estimates for the Sub-tasks of the Story which would typically be estimated in Story points.

If you want to use time tracking, you can log work against the hours of the Sub-tasks.

Take a look here for more info: https://confluence.atlassian.com/agile/jira-agile-user-s-guide/configuring-a-board/configuring-estimation-and-tracking

Jim

[eCPR]

Hi Jim,
I must be doing something wrong - or I am not following correctly, sorry.

Currently, I Can

• Add Story points to a story.
• I can add / edit REMAINING time for a Story

(These two are "practically" unrelated)

When I create a sub-task for a story,

• There is no field available for REMAINING
• I can however add to the work log of the sub-task.

I cannot estimate a sub-task.
I CAN estimate a "normal" task though - which then operates as I would expect.

So there "seems" to be something missing here. 

-Gavin.

[Jim Constant]

Hi Gavin,

It does get very confusing. It took me quite some time to feel like I understood what was happening with our configuration and of course it may be different from yours. Frankly, there are still nuances to it that I don't understand. I wish Atlasssian would improve their documentation to make this easy to grok.

It our setup, I can create a story and in my Create Issue dialog box I have three fields related to all of this: Story Points, Original Estimate, and Remaining Estimate. I think the Story Points label is just that - a label, and we could have it say whatever we want. Now, for a story, I only enter the story points and I leave the other two estimate fields blank. I never touch them.

Now for sub-tasks, which we break stories down into for all tasks necessary to complete the story, I have an Original Estimate field. We put the hours here when the team tasks out the story.

If you view the story detail page, you'll see the total hours Estimated and Remaining of all the sub-tasks under the Time Tracking section if the Include sub-tasks checkbox is checked.

We don't use the Log Work function because we only focus on how much time is remaining. In the board view, a team member will click on the task they want to update and then in the Issue Detail View pane on the right, they simply change the Remaining hours to however much they feel is left.

So, judging by what Phil Fox says above, there's a lot of configuration flexibility that I'm not even aware of and that probably account for the differences between what I'm saying and what you're seeing. 

Jim

[Usman Dembele]

We don't use the Log Work function because we simplest consciousness on how a whole lot time is final. In the board view, a team member will check here on the task they need to update after which inside the Issue Detail View pane on the right, they simply trade the Remaining hours to but plenty they sense is left.

[leandropbarreto]

Hi @Aaron Ko 

Usually, in Agile projects the "correct" sequence is:

Epic - for a User History with is not yet defined (in detail) what to do - there are no User Requirements.

History - for a User History with is defined what to do (they know the user requirements, etc)

Task - Something you have to do sequentially, and quite easy (To Do, Doing, Done), something like "create user name in system X" or "make coffee".

Sub-tasks are usually task who has Task or History as the main tasks.

The Story points for Epics is the sum of all History/Task they are made of.

I hope I was clear :)

Cheers,

Leandro 

[Deleted user]

Have you found a way to sum up all storypoints and hours from Sub-tasks up to Epic?