Difference and use cases of Jira issue types: Epic vs. Story vs. Task in Jira

[#1]

How are these issue types used in Marketing and Consulting?

Planning, structuring, executing and monitoring tasks and their progress in Jira is made possible by Jira’s elements called Epic, Story and Task. Definition and distinction is oftentimes done for developer teams and their processes, which is why we want to explain them in relation to Marketing and Consulting teams.

Set up from smallest to biggest element

Tasks

• Tasks are being used to plan specific tasks which should not take more than 1 working day.
• They could be part of a bigger project or planned by themselves.
• Tasks can be separated into subtasks.
• Tasks can be assigned to a responsible employee (assignee)
• Tasks are part of a sprint or scrum.
• They are being worked on actively, can be forwarded to someone else for feedback and can be marked as done when finished.
• Tasks can be cross-linked and can block each other.

Stories

Tasks can be part of Stories, which means that Stories can be seen as the overriding task, sometimes called User Story. Stories can be a bigger project, like the creation of new landing pages in marketing or the migration of instances in consulting.

• Stories entail the most important project information: vision, goal, benefits, project team etc.
• A story can be assigned to the project lead.
• All related Tasks can be linked to the Story. This allows users to go from their ticket to the Story to have a look at general information and for project leads to get an overview of tickets and their status.
• Teams commit to finishing Stories mostly in the next few sprints.

Epics

Epics represent either topics or overriding goals, which are then broken down into Stories and Tasks.

• An Epic could present the theme/topic to which a task belongs or represent a big project, for example “Migration customer X” in consulting or “Website Relaunch” in marketing.
• Epics are oftentimes not part of one, but of many sprints. Epics are most likely part of a roadmap for products, team or customer projects.
• Stories and Tasks belonging to the same epic, are sometimes linked or co-dependent.

By using Epics, Stories and Tasks, Jira teams are able to record small and big successes throughout the year. This helps keeping momentum. Project leads and stakeholders are at the same time keeping an overview and status updates along every step of the way.

Practical example from Actonic's Marketing team

Content Marketing

1. Epic: Our Marketing team uses Epics in order to define the topic of the task.

Example: “Articles”

2. Stories: We use Stories to plan big to-dos or projects, which are going to be part of multiple sprints and with multiple tasks and employees. The project lead is assigned to the Story to keep an overview.

Example: Article creation “Epic vs. Story vs. Task”

3. Tasks: Tasks are single to-dos, assigned to one employee and planned in a specific sprint. Tasks are oftentimes part of a story and cross-linked.

Example: Article Research, Article creation, Proofreading, Publishing

Practical example from Actonic's Consulting team

Implementing a Jira instance for a company

1. Epic: In our Consulting team Epics represent single services.

Example: “Consulting”

2. Stories: The story represent the goal, namely implementing a Jira instance for a customer.

Example: “Implementing Jira instance Customer X”

3. Tasks: Tasks are single to-dos and problems, which should be done and solved before going live with the new Jira instance. Tasks are finished weekly by the consultants.

Example: Record current status, Prepare meeting, roadmap implementation, testing

P.S. We are also holding a free webinar "How to get started in Jira" on April, 28 and we'll be happy to see you. Sign up and learn more about the best tool for project management.

[M Amine]

Great article to read

[Sohel Ahmed]

@Michael KolodziejYou are kind of correct in respect of time management but you have the choice to minimize the excessive usage of documentation. You are also correct, this Article failed to explain what is an Epic and what its actual usage is. Most of the time, we do not see any visible difference between Story and Epic and it is very uncommon of the practical usage of Story and Epic together. That does not mean it is a total waste of money or time to use Jira. You will must be benefited if you can customize it as your need :-).

For example, I stopped writing User Story and it helps me to avoid using 'Story'. I directly use Epic for a new feature or big changes and break down the Epic in multiple tasks. That means, all related tasks are linked to the Epic and this allows users to go from their ticket to the Epic directly for the general information of the new feature or changes. It reduced our effort a lot and save a significant amount of time.

[Salman.Arshad]

Useful details, Thanks Andrei.

[Tiago Massochin]

"Tasks can be part of Stories" so why can't you add a task inside a Story as you can add Stories to Epics?
At the moment, it is only possible to create subtasks inside stories, or you can add a task to a story as a linked issue, which is not the same thing as "be part of Stories."
It doesn't make sense to affirm that while Tasks and Stories are at the same hierarchic level. 

[Andreas Haaken _APTIS_]

This is related to the nature of Issues and Subtasks:

Subtasks are "parts of" an Issue and therefor very hard to move

Issues are the basic element in Jira (everything is an issue, even Subtasks but with restrictions), so Task and Story are just 2 variants of issues. 

Epics are Issues to, that have the ability to be parent of others, a very useful characteristik.  

this leads to a possible setup of any issuetype being "child of" an epic but not of another issue. 

For that you can use several addons to change that:
- Structure: creates a hierarchical structure without touching the issues, its a selfcontained structural addon to Jira
- Epic Sum Up (our Plugin): adds the ability of being a container for other to any Issuetype you want and summarizes any metric in a Summary panel

Bothg allow you to make Stories parents of other issues, which can help you to create deeper structures beyond Epics.

backside: Scrum Boards do just support Epics as Containers. 

Hope that helps. 

[jukjuyt65gyehtgwreq3t4rwhtj6k]

If Andreas' assessment of issues is true and stories and tasks, for all intents and purposes, are on the "same level" and can't be added as sub-issues to one another, then what is the point of this misleading article?

[Josue Lopez]

Perhaps it would be good to provide a small caption when selecting epic or story, I have found that not everyone knows how to differ the difference. 

[Sal Pike]

I´ve been dabbling in Jira for a few months now, and I found the simplicity of this article helpful, as well as the user anecdotes. I now feel much better about creating my own Kanban and Roadmap.

[Haolin Zhang]

It is a concise but useful introduction!

[Kevin Greer]

For me this brings to mind a debate I had in a previous role where I was responsible for managing an application that received bug reports and change requests from users.

I felt strongly that we shouldn't ask users to pre-determine the categorisation of the "thing" they were highlighting; users shouldn't be expected to know the difference between a change and a bug - only that they wanted something done.

Initially we couldn't agree what to call the "things" users should submit but eventually settled on "work request". On receipt of work requests we had a process to triage and classify them (as bug or change) and another process to manage the work request depending on whether it was a bug or a change.

It seems to me that the story/task debate in Jira is similar. The ticket is a "work request" and calling it a story or task does not, imo, add any information/understanding that should not be apparent from the description and associated conversations.

There is no meaningful hierarchical difference between a task and a story in Jira and as such I don't believe having 2 labels to describe the same thing is helpful and I'd rather they weren't used at all!

Our goal is to get to something that is sized appropriately to convey value and be tested - artificial distinctions just create noise that makes that more difficult!

[Dan R]

@Kevin Greer 

"There is no meaningful hierarchical difference between a task and a story in Jira and as such I don't believe having 2 labels to describe the same thing is helpful and I'd rather they weren't used at all!"

^^^ Yes. That. ^^^

The nomenclature should reflect/support the hierarchy. I've got my concerns/challenges with the hierarchy, too, mind you... But specifically this article didn't help me understand the process or methodology to follow, as Tasks are Stories are Tasks. Do they have different fields or attributes or flow? If they do, that practical distinction would be good to explain here, or point to an explanation...

But the article as is kind of leaves me, practically speaking, nonplussed. 

[talar.kouyoumdjian]

I want to implement the following hierarchy as part of my company's projects:

1. Epic

2. Business story

3. Task

4. Subtasks

But want to male sure the tasks are linked to the Business stories as parent and child and the subtasks as child for the tasks; since currently the percentage of completion that shows on the level of business story is directly related to the % of completion of a subtask. I want to implement the following hierarchy business story -> task -> subtask and when I'm checking a BS to reflect the % completion of a task instead of a subtask. Is thay doable???

[S.Anastasiou]

What if something small but essentials comes up that was not foreseen in any active story or epic?

Can a task stay orphan?

[Sankar naidu_m]

@Sohel Ahmed is UAT execution is required for a Task ?

I have User Stories and tasks for a application. Generally for user stories will perform UAT but my doubt is for Task also we should perform UAT or its not required? TIA

[Sankar naidu_m]

• @Tiago Massochin is UAT execution is required for a Task ?

  I have User Stories and tasks for a application. Generally for user stories will perform UAT but my doubt is for Task also we should perform UAT or its not required?

[Roman Bozeman]

Hey Kevin Greer.

You said a mouth full! Tasks and Issues are the exact same thing in Jira. I prefer tasks and subtasks. What does 'user story' have to do with something on my to-do list? We use user stories as they are named. They are for reporting an experience from a user. How is the software behaving? Then we ask the classic question -- 'Is this a feature or a bug?' LOLOL

[anbalaganj]

Should be Epic -> Story -> Task/Bug -> Sub Task. Currently we can't create Tasks under a story. I like how dev ops do it. Epic -> feature -> PBI -> Tasks/Bugs