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?
A JIRA Story is broken down into Sub-tasks. When you do this, you can have the Sub-tasks appear under their parent Stories 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, on the other hand, is at the same level as a Story. But it's a stand-alone issue type that can't be broken down into Sub-tasks.
Hope that helps.
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.
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.
Hope this clarifies as well as extending the answer.
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"
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.
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:
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!
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
I must be doing something wrong - or I am not following correctly, sorry.
Currently, I Can
(These two are "practically" unrelated)
When I create a sub-task for a story,
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.
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.
Teams break work down in order to help simplify complex tasks. This is often done iteratively, with tasks being broken down into smaller tasks and so on until the work is accurately captured in well-...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events