Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,364,338
Community Members
 
Community Events
168
Community Groups

How do you explain differences between Epic, Story/Tasks and Sub-Tasks ?


I'm curious. When people ask you about the differences between Epic, Story / Tasks, and Subtasks, how do you answer them?

Are you talking about time tracking? t-shirt size? Story points vs work logs? Feedback loop with users? Roles and responsibilities?

 

Jira_WBS.png

 

2 comments

Niranjan Rising Star Oct 05, 2020

Hi,

We have a lot of experts here. My understanding is that

Epic is a larger chunk of work in JIRA  and associated with releases. In JIRA's context a grouping of related Stories/Tasks. Usually a MVP.

Story often estimated in Story points is a smaller unit(compared to Epic) of work aimed at a functionality/feature. Integral part of Sprint planning. Stories are usually groomed and prioritized. (From user Point of view)

Tasks are same level as stories in JIRA , but more of engineering perspective.

Sub-tasks - JIRA defines it better. They are issue types to split up larger pieces of work into tasks that can be assigned and tracked separately by your teams. 

 

Feel free to add to the discussion.

Like Sedera Randria likes this

Interesting. I like your feedback,

In many situations, I often use the following criteria to explain what's a "larger chunk of work": Epic = Related to a specific budget account (we can define in Tempo). Used at the management level

Then, the use of Epics makes sense also for traditional projects :-)

What do you think about that?

Kat Marketplace Partner Oct 05, 2020

I talk about how Epics are a container/grouping that can be reported on and typically spans multiple sprints. Epics could track project phases, specific product functionality or any other way of categorising work.

Stories/tasks is the standard issue type representing work that needs to be done typically sized to be able to be completed in a single sprint (for development or internal work). The assignee may change while the issue is being worked on.

I have rarely used sub-tasks, but when I have they have been for a task that needs to be repeated in multiple environments or for multiple customers so the workload can be shared.

Like Sedera Randria likes this

Comment

Log in or Sign up to comment