epic vs story vs task

[Brian Shanblatt]

Related content: Epics vs stories vs themes vs initiatives 

[Deleted user · Accepted solution]

The way I've been approaching the distinctions of issue types is this - I'd LOVE some feedback or alternative suggestions to consider:

• Epic - A general use case that is a collection of features (user stories). (Use Fibonacci numbers to estimate.)
• User Story - Represents a user feature. (Use Fibonacci numbers to estimate.)
• Sub-Task - Represents development tasks to accomplish the user story. (No story point estimates.) Generally no more than 1-day tasks. You can either count the number of sub-tasks or time estimate in days in your retrospective to evaluate if your story point estimate for the User Story was accurate and adjust accordingly - assuming you have some velocity history to compare to.
• (Engineering) Task - We used to call these "Dev Stories" (in a pre-Jira project) - represents a set of engineering work that is not directly related to a user story. The team should try to anticipate "Dev Stories" and add them to the backlog sooner than later with estimates (Use Fibonacci numbers to estimate) so the PO can plan milestones.

An example of these distinctions could be:

• Epic: User Authentication.
• User Stories:
  • User Login screen.
  • Forgot Password workflow.
  • Lock account after too many failed attempts.
  • Google login support.
  • Facebook login support.
• Sub-Tasks:
  •  User Login screen:
    • Design login page.
    • Cut SVG icons and images.
    • Implement login page HTML/CSS/JS.
    • Create SQL scripts to create tables.
    • Create SQL scripts for stored procedures.
    • Create web service REST API for user resource.
    • Hook up login page to web service REST API.
  • Forgot Password workflow:
    • ...
• (Engineering) Tasks:
  
  • Setup GitHub project repo.
  • Setup GCP (or AWS) account, containers, and services.
    • (There might be Sub-Tasks for these too)
    • ...
  • Setup Jenkins CI pipeline.
  • Design overall (high-level) system architecture.
  • Research and decide on unit test and mocking framework.

What do you all think?

[Steven Gerson]

I agree on the Epic, Story and Sub-Tasks.

Why not write those "Engineering" tasks as stories with sub-tasks?  They can be associated with an appropriate epic.

I ask, what is the value that these tasks are bringing?  The value should be defined at the story level.

[Deleted user]

In Jira, (User) "Story" and (Engineering) "Task" are at the same level, so you can have sub-tasks under both, and both can be assigned to epics. We use both to make the distinction between a user-facing/requested feature and something the team needs to do.

[Ramon Lluis Felip]

I agree 100% with that approach.  I use the same as a matter of fact :)

The use of tasks is key, because sometimes the PO is not aware of some workload that is required to achieve a goal (processes like refactoring, BD maintenance - schema changes, etc .. -, API versioning ... ) may not be directly linkable to a user story specifically, but they need to be present on the backlog. 

[Eugene Davidovich]

I agree and we use the same approach

[Wasantha Wijayaratna]

How about considering those 'Sub Task' as 'Engineering Tasks', so there is no Sub Tasks at all, the logical hierarchy is as follows:

EPIC -> STORY -> TASKS

TASKS can be estimated (Story Point) and assigned to different teams, tasks can be tracked in burn-down reports. 

Advantage in the above approach is technical component level Story Point estimation can be done and sum of Task level Story Points is total Story Points of the Story.

Tasks can be linked to Story.

Comments Please...

[prafulla_girgaonkar]

Though it is not perfect.. it is a practical approach. I come from Rally world. Just go confused with Atlassian philosophy. Now with this comment I am comfortable to take up story writing task.

[Simon Shen]

Thank you for the information. It's very helpful!

[Deleted user]

What about the workflows that stories and subtasks follow? Do they use the same workflow?

For instance: Based on Mars example:

Story: User Login screen:
      Sub Tasks:

• Design login page.
• Cut SVG icons and images.
• Implement login page HTML/CSS/JS.
• Create SQL scripts to create tables.
• Create SQL scripts for stored procedures.
• Create web service REST API for user resource.
• Hook up login page to web service REST API.

Most likely, subtasks (and tasks) will go through the workflow: 
Coding->Code Reviewing->Testing 
since they are development tasks (there could be more states). But the story itself doesn't need to go though this workflow. Perhaps the workflow stories will follow will be something simpler like:
ToDo->InProgress->Done

The question is: how do we keep two flows in Jira. Do we have 2 different boards, one for stories and another for subtasks/tasks?

[Patrick Duchesneau]

Over time, I have been used to do the same as Mars describe and it works perfectly

Epic: Generic or large matter to accomplish, but smaller than the project itself

Stories: Features viewable by the user. In fact , stories are often derive from the sprint epics, with the customer, during sprint planning. So they are in "user terms".

Tasks: Same thing as Story but more internal stuff, which does not correspond to demonstrable stuff 

Sub-task: Steps to do within a task or story, necessary to complete them. 

[Deleted user]

@[deleted] regarding workflow, you can have both statuses for subtasks and stories in one workflow (board) - just don't move stories into those statuses strictly for subtasks.

In your case, the board will look like this:

ToDo|InProgress|Coding|Reviewi g|Testing|Done

Stories move to InProgress and stay there while subtasks move through Coding, Reviewing, Testing, and Done. When all subtasks are Done, move the Story to Done.

In our team, we use to keep it simple:

ToDo|InProgress|QA Ready|Done

InProgress encompasses coding, code review and anything else the devs need to do before it's ready for QA. For us, subtasks rarely move to QA Ready, typically they go directly to Done. When a Story goes to QA Ready, whatever testing subtasks waiting in ToDo start moving to InProgress and then to Done. Once all subtasks are Done, the Story moves to Done. 

[Deleted user]

Makes total sense @[deleted]

Thanks!!

[Marco Alabruzzo]

Very good organization system!

[Rich Hale]

I haven't read all these comments, so hope I'm not repeating.   with the "Git" and other DevOps stuff - I'd probably put them into a separate DevOps support JIRA project.   I don't think they relate to the Login EPIC.

[Marcos Villasanti]

I have read the comments carefully and now I understand much better the difference between the epic and the historical point, Thank you.

[Al Schnopp]

Thank you, this explanation open my eyes.

[Deleted user]

@Rich Hale : if one has a separate matrixed DevOps team with their own JIRA board, you could certainly do so. If one has a self-contained team that needs to do the devops tasks, then it makes sense to keep it all in one project/board.

[Meenakshi Sundaram]

@[deleted] : If we keep separate JIRA boards for DevOps and Development/Engineering how to we total estimation/cost for the project and check the velocity?

[Rabbit Stoddard]

@Meenakshi Sundaram I go with having a higher level project for Initiatives/Epics for the project as a whole and making all of the devops and engineering tickets roll up to that. But ultimately, you're talking about Portfolio level concerns, which is how you handle that kind of deal. 

[sept0]

I would not go with Subtask in Stories/Tasks. As a story should be finished in one sprint you certainly don't want to have a bunch of sub tasks attached to a story that you can't finish.

We keep Epics, Stories and Tasks as our main way to go.

[Johanna De Klerk]

this is a nice breakdown of an EPIC, User Story and Tasks as I complete ACM (agile Scrum Master) Course

.

[Iván Felipe Villarroel Ramírez]

Thanks for the clarification!

[Chris]

This has given me a clearer distinction of these than i have gotten reading the documentation. Thank you for this

[Mark R]

@Mars I really like your distinction and descriptions - they are very clear and I've been trying to implement it this way.

I have a couple of questions:

1. I have picked up ownership of a Jira Kanban board where the team are (roughly) following this approach. However, I see many issues currently added as 'Tasks', which appear to be written as 'Dev stories'. Often they are written as follows:

• As a developer, I need alerts generated from X service, so that I can be informed about errors as soon as possible and resolve before it affects users
• As a developer, I need to be able to access X API in all environments, so that I can implement integrations with it
• As a developer, I want to use X library so that all messages are logged in a standard format
• Limit X API's response to the required field

Are these the types of things you would class as (Engineering) Tasks? I'm wondering if this 'Task' type is getting overused when they are are related in some way to stories, although not directly. I'm struggling a bit to make a definition between what should and shouldn't be a (Developer) task.

2. I just wondered how you use UX/Design tasks? Often I would create a sub-task of a story specifically for UXD, but in some cases, a UX/design task can cover multiple stories (for example design a section of an application that needs to be considered holistically). In this case would you create a story or a task specifically for UXD?

3. What is the best practice for 'discovery tasks'. Is it best practice to create a story sub-task, create a Spike issue type or a combination of both?

Thanks in advance

[Chander Inguva · Accepted solution]

Hi Brian,

             If you are looking for difference between these three 

Epic is An epic captures a large body of work. It is essentially a large user story that can be broken down into a number of smaller stories. It may take several sprints to complete an epic. 

• There is no true difference between a Story or a Task in JIRA Agile.
• If you need to break certain Stories up into items that have to be assigned to different teams I would advise you to convert this Story into an Epic and make new Stories of the sub tasks, these Stories can then be assigned to different teams.
• Otherwise I would simply advise you to use sub tasks underneath stories (these are not viewable in the plan mode, but they are viewable in the work and report mode of your Agile Board).

Regards

Chander Inguva

[Mike Howells]

When you say there's no difference between Story and Task I guess you mean that there's no technical difference in that they're both "issues" as far as JIRA is concerned. So they get shown the same way on a board, for example.

There definitely could be a semantic difference in that a Story could be about something of value to users, whereas a Task could be something of value to the team. The two are likely to have different workflows and different fields to reflect those purposes, depending on how the project has been configured. 

[Mr ISAAC EPIGNOSIS]

Thanks, @Mike Howells and  chander inguva for your kind update.

Best Regards

[Adam Menary]

Chandler  there a diagram of the structure?

[Vineeta Srivastava]

Epic is a large story, and not much difference between story and task

[Gonchik Tsymzhitov]

@Mike Howells Thanks for clear describe

[Kamran Khan]

i think it is the best diagram to understand these all types.

[Ivy Clark]

The diagram in Bob's video is misleading as it suggests that Tasks sit beneath Story, which this is not the case in Jira. His video explains the generic concepts which is not specific to Jira. Theme does not exist in Jira, but some organisations use 'Initiatives' to represent that. 

In Jira, Epics can be broken down into tasks and stories, which can in turn be broken down into sub-tasks.

[Nic Brough -Adaptavist-]

It's not badly misleading - Tasks can sit beneath Story in Jira.  It's about the configuration though.  It would be better to think in layers.  Epic is one layer, Story a second layer, and sub-tasks third.

But there can be many issue types in the Story and Sub-task layers.  By default, Jira creates issue types called Story and Task in the "Story" layer, along with several others.  And by default, "sub task" and "technical task" are added in the sub-task layer.  But an admin can add, remove or rename them.  Almost all of us mess with these schemes.

And, specifically, a lot of us rename "Task" to something else or remove it, then add a sub-task type called "Task".  When an admin has done that, Bob's video is accurate.  It's quite common to find a Jira system that has Epic -> Story -> Task. 

[Rich Hale]

As I'm reading this, I have a PM who's really confused, and she says she's always thought of "TASKS" as sub-level to "STORIES" - but I tried to explain that she is thinking of a "Sub-Task" - which also confuses her.    Layers is a good thought, but JIRA documentation and culture don't talk about layers, so it's a new concept to explain, and you sort of always have to explain it.

Atlassian should:

    Fix the name of a "Sub" anything to the same thing across the board - like "Sub-Issue", and then give it a "type".   So JIRA would then have:  Issue / Issuetype, Sub-Issue/Sub-Issuetype (where the "types" are customizable by Admins, and include the OOB standards - such as "bug, story, etc...").  By means of these consistent relationships, I think it would reduce confusion about "sub-tasks", "tasks" and cause better overall understanding of the relationships.

[Bill Powell]

Should?  FORCED?   No.

[Lorena Holbrook]

One difference in the default set up with "Task" vs. "Story" is that "Task" does not allow me to add story points, only duration and "Story" allows story points and duration.  Is this acccurate for the default setup?

[Sangwook Kim]

@Lorena Holbrook In my backlog, I could assign story points to Tasks also. 

[Lucy Buecking]

Do boards represent stories that have various tasks?  Or is that something different?

[Rabbit Stoddard]

Enabling the story points field on the task issue type is possible (and one of the more uncomplicated tasks), but I don't think it's there in the most basic workflow scheme. I'd look at the "where is my field?" option in the admin dropdown, if it's there on your view. If not, then reach out to whoever's managing your instance (hopefully, a JIRA admin).

A board is a view that represents a body of work being worked on. It can show pretty much anything according to a filter, so if you want subtasks to show on it, you can make it so, or you can exclude them. 

[Mike Howells]

If you want team velocity to be a budget for the product owner to spend, representing how much user story work the team can get done per sprint, you should only put points on a Story or Epic and never on a Task or Bug.

Velocity works best when treated as a story budget. It allows that essential separation of responsibilities in Scrum and XP where the product owner decides priorities, while the product developers decide how much they can deliver per sprint.

Any non-Story work is then counted as drag, reducing velocity. The team has to decide how much drag is required to sustain high velocity and high quality. If they skip that work (e.g. fixing bugs, automating builds) then eventually velocity and quality will take a nose-dive.

If instead you treat velocity as "how much work the team can do per sprint" then you are not giving the product owner a budget to spend on stories. You will have to waste effort negotiating with the product owner to make room for non-story work in every sprint, which is often for technical things that the product owner doesn't understand or care about. The team will struggle to distinguish between user-value and team-value, making it easy to inadvertently favour one over the other.

[Avdhesh Chauhan]

Hi @Brian Shanblatt

As stated by Chander, Please have a look at these:

Epic : https://confluence.atlassian.com/agile/jira-agile-user-s-guide/working-with-epics

Story : https://confluence.atlassian.com/agile/glossary/story

Task : https://confluence.atlassian.com/agile/glossary/task

Thanks

Avdhesh

[Rupali mahadik]

Hi Avdhesh ,

Can you please give day today example that explains what epic story and task.

Homepage (epic)        

- Carousel (story)            

- Backend development to load carousel images (task)             - Layout and styling of carousel (task) 

             like above

Thanks,

[Robin Surland]

Our team adds tasks as "technical tasks" that are large enough to be stories (bigger than a sub-task), but do not directly add value to the customer.  Using a different issue type lets me create a customer focused dashboard for stakeholders and another one with all issues for the team.

[Ken Dellinger]

@Robin Surland, do you assign Story Points to the "technical tasks" or the User Stories or both (or something else)?

I like your approach and plan to use it on a project I am about to start. Just need to figure out some of the details and how to fit them with our team.

[Robin Surland]

Our team estimates the tasks, but we had a historic problem with our internal customers trying to hold the team to large story estimates made six months in advance. I have been thinking about adding a T-Shirt size field and using that for stories and keeping the points attached to actually work we know enough about to estimate. I know a lot of teams would say that the stories were simply not broken down enough to begin with, which is probably true. If we had more layers of Epics, like themes maybe, we wouldn't have to use stories in this way. In the end, anyway you can simplify the customer's view so their asks don't get lost in projects with thousands of issues, the better. 

[Mike Howells]

+1 on making it easy to see which backlog items deliver value to users!

I would avoid quoting estimates in person-hours for the very reason you found: stakeholders will hold you to them. 

Story points are intended to be used on items for which you want to be able to estimate delivery times, which usually means those that deliver value to users or the business. By getting a measure on how many points a team can deliver per sprint, and putting points on the user stories, you can estimate how many sprints it will take to get everything you want to users. 

The points are meaningless to anyone outside the team, but if you know the team's "velocity" (points-per-sprint) you can estimate by which sprint they'll deliver the stories required. That way you can give the customer a time-box, but of course priorities will change so you reserve the right to change which stories get done to get them what they need. 

[Mike Howells]

The idea of Scrum/Agile is to break down deliverables into small, incremental pieces that each give some value to users. By small I mean can be done in one sprint. If it’s not sprint-sized then it’s an Epic, and you need to think hard to break it down further into smaller pieces of value, tracked as Stories. 

I recommend going on a Scrum training course. Kane Marr does an excellent one. 

[El PR]

Agreed, stick to story points and avoid the agile trap of tasks, I would only use tasks if teams are offshore and you don't have transparency of teams and their work, or teams that like to go to the detail then let them use tasks... 

But story points should be measured on stories and burn downs or burn ups should all be based on the progress of the story would be my suggestion. 

[steve terelmes]

Agile is a philosophy and as such is implemented with vary degrees of rigidity. I teach JIRA classes to many students who use Agile. To date I have not found 2 companies that use Agile in the same way.

JIRA is a software that attempts to facilitate the Agile philosophy. As such, JIRA provide a fairly broad approach to agile terms and functionality.

In general, Epic, Story & Task are all Issue Types in JIRA and therefore can be organized in any heirarchy the users wishes (via linking and advance workflow rules). For example, JIRA would even allow you to make an epic dependent on a task - though no one would likely ever want that.

Once you get to scrum boards (and also JIRA portfolio), Epics do have some unique functionalities that you do not have with any other Issue Type. 

[Santosh Maurya]

This is how we use Epics, Story & Task ..

Epics are used as functional classifications (verticals) of our product, it makes more sense if we need to do some kind of measurements... Epics in this case will live as long the project exists.

Story is a kind of work that directly or indirectly affects our end user experience.

Task is a kind of work that is pure technical, mostly NFRs, deployments, optimisation, code level, configs, etc ...

I think we must use these issue types to best suite our requirements ...

[David Heller]

Why can't you leverage labels on stories/tasks for what you want to achieve currently through epics?

[Josch Bencke]

Hello @David Heller, 

Epics are the vague, large clouds far back on the horizon. Once you get closer to them you will notice more and more details, usually sorted into Stories.

The stories are the actual items for getting things done, the epics are the grouping tool to keep an overview to allow hierarchical relationship. 

Grouping, you could surely do via labels, but labels are just a bunch of strings, get mistyped, might be attached anywhere and cannot be classified. With epics, you can actually work with them and have them 

• have fields to enter structured information
• have descriptions for freeform information
• have attachments
• have workflows 
• assign responsible person
• link other items incl. classification like "blocks, inherits, relase, relates, makes fun of ..."

[El PR]

I agreed some places use Features to group stories in order to understand the feature they are delivering and the value associated with that feature and the collective stories.

[Mike Howells]

To break down the work to implement a user story I use Technical Task sub-tasks under the Story issue if we want to assign them to different people, for example. This makes it easy to keep them in the context of the story and to see when they've been completed. Sub-tasks are similar to issues but always live under another issue.

For ambitious user stories that are too large to estimate reliably, I use an Epic issue and break it down in to separate Story issues that each deliver some value to users but are small enough to estimate reliably. 

For work that needs to be done but is not releated to a user story, such as setting up build automation or upgrading a library, I use Task issues so we can easily see which backlog items are delivering value to users and which are for the team. A Task doesn't get story points, for example.

[Warren Haines]

Thanks Mike, Like your explanation 

[Anatoly Spektor]

Thank you very much for this question. I have recorded a video, in case you like to learn in this format, where I show you the difference between the three:

https://www.youtube.com/watch?v=8fLNtFJkj10

[jamie royce]

In my Jira configuration I do not use Task at all but only have Epic / Story / Sub Task in use. 

I have not found any need as a Project Manager to have both Tasks and Stories and just call them all Stories. 

I also created a "Documentation" issue type and a sub-type "Requirement" and store all my project requirements in the Jira project as well. 

[StepanStulovGoodlyInnovations]

The biggest misconception about stories/tasks is that one story generates N tasks, where each task is based strictly on one story. This is almost never true. A collection of stories generates a collection of tasks, where each tasks belonging to only one story is a rare lucky special case. But more likely you cna have 2-to-3, 5-to-1 or 13-to-17. Drop the idea of tasks being children of one story and you're golden.

A collection of stories describes some software change from the user perspective while a collection of tasks describes that same software change from the development team perspective. Conversion of the former to the latter is usually what they call sprint planning.

Don't enforce hierarchy where there is none.

As for sub-tasks. In my team we simply agreed to not use sub-tasks due to a very confusing name: they're not a task granularity organization tool actually, despite the name. Sub-tasks are a redundant, unnecessary and misleading concept imho.

[Rich Hale]

Stephen - I appreciate your comments here, just as the PMO side of our teams has just brought the following (invented) SDLC/AGILE Edict into Law: Each Story will always have: (1) RQ Task; (2) Test Task(s) (QA); (3) Coding & Developer Task(s); (4) Test Automation Task (QA); (5) Release Task; and possibly more. Along with this, an additional set of articles for each transition, that states "...a JIRA Story cannot continue to the 'next status' until Task N is completed, and Done...". So, now after having shortened our Scrum workflow from 13 statuses to around 7, we're now looking at the workflow going from the 7 statuses, to close to 20!   I've given my feedback, but now just watching the team make committee decisions.   Thoughts?

[StepanStulovGoodlyInnovations]

Stepan.

My thoughts, given my previous post, is that what you have is not really stories anymore, since they're already pre-digested into macro-tasks for the developers to split into sub-tasks by role/discipline/sub-team. "True" stories are something that comes from a pure user perspective with theoretically zero knowledge of the implementation. To write real stories you need to "forget" you're working for your own company.

Then again, the fact that all your stories are "standard" and usually result in the same collection of tasks in sprint planning is also nothing illegal. From that perspective your model seems perfectly fine.

Seven statuses sounds like much but I guess your workflow justifies that.

[Mike Howells]

For cases where implementation tasks are needed by multiple Story items, I would create them as Task items in the backlog, since sub-tasks don't really make sense.

You can use issue links to show which Story depends on which Task. You could also add the Task to an Epic if every Story that depends on it is also part of that Epic.

You should still not put story points on those Task items. You already put points on the Story items, so it would be double-counting. See comments above for why story points (as their name suggests) only belong on Story items (or Epics).

[Chris Nicosia]

Here is a really nice article to help answer this question: https://moduscreate.com/blog/jira-using-epics-vs-components-vs-labels/

[Vickey Palzor Lepcha]

The literal meaning of those three words are also actually what it means in JIRA - their meaning and their features.

Take an epic from a history - it will be formed of many stories - and each stories may have their own events ( tasks)

I understand it as simple as that.

[MahendraH]

I am answering this from a coaching point of view. This is how I try to explain in my sessions. I use the SAFe structure . Epic is something that you cannot touch and feel, Feature is something that you can touch and feel and experience, Story is we all know which abides by 3Cs and INVEST and finally task is technical nature to achieve the story. 

[Mike Howells]

Note that there are two flavours of "task" in Jira by default (although you can configure more):

• Task issue type.
• Technical Task sub-task type.

The latter is intended to be used to break down a Story into multiple technical implementation tasks assigned to different people. Sub-tasks are a special kind of issue in Jira that can only live as children of a parent issue. On an agile board you can chose whether or not to show sub-tasks.

There is some debate here on when to use the former. I advocate for using a Task to represent work by the team that doesn't relate directly to a specific user story, e.g. implementing tools that help the team work better. 

The tasks of Scrum are best represented using Technical Task sub-tasks as that works best with current Jira features.

[SUSHIL BHAT]

The problem with sub-tasks is that you can't include sub-tasks in a Sprint independently. Suppose if your story has a bunch of sub-tasks and not all of them can be included in one sprint, you can't choose some of the sub-tasks for adding these to a sprint.

[Deleted user]

For our team we had to decide on one of two options to deal with this:

1. Split the User Story into two and Move the unfinished sub-tasks from the original to the new "part deux" User Story. (Granted that Jira UI isn't the friendliest about moving multiple sub-tasks to a new parent Story.)
2. Just move the entire User Story over to the next Sprint if it's not done - you don't get the story points in the sprint if it ain't done.

What we've ended up doing is option #2, unless we anticipate before the sprint starts that a User Story is definitely way bigger than can fit in one sprint and preemptively break it up into smaller stories.

[Nic Brough -Adaptavist-]

>The problem with sub-tasks is that you can't include sub-tasks in a Sprint independently.

That's not a problem, it's correct.  A sub-task is part of the story you are telling people you are going to complete during the sprint.  You do not commit to doing part of a story in a sprint, it's either going to be done or it is not.

@[deleted]- your approach is pretty much right, except that you should emphasise doing point 1 before you draw anything into the sprint!

[Lil D]

Hi All,

Bottom line is - JIRA schema could be set different and its setup adaptable to the company needs.

I have worked with different JIRA schemas with different companies in the past.

Out of all of them the best one (and the one that make most sense to utilize JIRA's options) is this:

1. Epic (organizational break down, something that only one part of organization is working on and the other don';t need to see. For example different software type - core team and customization team could have different epic. or 2 different apps)

2.  Under Epic goes your Project - whatever is your PM tries to implement - usually driven or created by PM.

3. Under Project goes  - your Stories - those are driven or created by BA pr Product manager and they are cover your Requirements (user stories) - what they want to see once project implemented.

4. Under Stories go Tasks, they are Engineering tasks - what Dev will do to fulfill the Story/requirement. 

5. Under each engineering Task go sub-tasks (for example QA specific). And if QA cannot complete Sub-tasks because issue is found - they link it to this specific sub-task. That way Dev sees what his tasks blocked by, as he cannot close the task without close all sub-tasks first. 

In this setup everyone under the same Epic working on the same product or client or whatever you setup. It is easy to find your specific project and everything else cascade down from the project, so it is easy to see truck, find and analyze through JIRA tools.

[Gerry Claps]

Most Agile teams I've worked with will map their requirements as follows:

• (Epic) User Story = Epic (in JIRA)
• (Sprint-Ready) User Story = Story (in JIRA)
• Task = Sub-task (in JIRA)

The intent...

The intent behind this is, when requirements are first created, they are nebulus and Epic in size (i.e. they take longer than your Sprint/Iteration to complete. Once you begin to break this down into pieces that can fit within a Sprint, these requirements become Sprint-ready. To track and monitor progress within the Sprint itself, as well as to help with forecasting a team's capacity, you can break down these requirements into individual tasks or technical steps required to resolve them.

How this works in JIRA...

How this works in JIRA is, you create Epics first, then you break these epics into Stories which you link back to the Epic. When you're monitoring progress in your Sprint, you break down the Stories into Sub-tasks and track progress via these on a Scrum board. Of course, this is an optional approach, but one I've seen most Scrum teams undertake.

Remember, it's all just a name...

In JIRA, you can have as many Issue Types as you like and you can call them whatever you like. If you prefer the naming convention of Requirement over User Story, feel free to use that instead.

[Kevin Mandeville]

So procedural question about breaking down Epics...who typically does this? I've worked at companies before where the PO was responsible for getting down to the Story level. My current company we seem to be getting Epic level only. That doesn't seem like the correct process

[Mike Howells]

The team does it, and the PO/PM is part of the team. 

The PO must be involved as they represent the user. Otherwise developers working on their own tend to break it down into technical tasks rather than incremental value to users. 

[cierralewis]

So keeping with the hierarchy: Epic -> Story -> Sub-task. What is the most efficient way to track sub-tasks during a Sprint if they cannot be seen in the backlog? Meaning if I break a story into smaller sub-tasks, but not all the sub-tasks are completed prior to the end of the Sprint and has to be rolled over.. how would you account for that? It's not like you can see them in the backlog... 

[Mike Howells]

You can configure a Scrum board to show sub tasks under Stories.

You might want a separate board for stand-ups where you only see the stories, so you can focus on updates relating to deliverables. 

[Deleted user]

Question about estimating Epics vs Stories:
If, in the beginning of the project, user stories are typically of Epic proportions, do you use the same scale of story points between Epics and User Stories (be it T-shirt sizes or fibonacci numbers)?

In other words, would Epics be in the say 8, 13, 21, 34 range while user stories should fall within the 1, 2, 3, 5 range?

Or, do you use the same fibonacci range 1, 2, 3, 5, 8 for both Epics and User Stories, but assume that they are at a different scale when used at the different hierarchical level?

How do these two approaches affect Jira reports and velocity calculations, if different?

[Artur_Mkrtychian]

How would you organize the following scope of work in JIRA? What type of issue would you use?

Example:

Graphic of expenses

• Design for web. Graphic of expenses.
• Design for mobile. Graphic of expenses.
• Back-end. Logic for Graphic of expenses.
• Back-end. API for mobile. Graphic of expenses.
• Back-end. API for web. Graphic of expenses.
• Web. Graphic of expenses.
• Mobile. Graphic of expenses.

[Alwyn Pereira]

Ill interpret it in the following manner.

The product owner wants to add a capability to visualize expense in the product.

Id treat his need as a Feature, and capture it as an Epic, and explain the high level need for this feature.

Task 1

• Back-end. Logic for Graphic of expenses.

User Story 1 - Web

• Design for web. Graphic of expenses. - Sub Task.
• Back-end. API for web. Graphic of expenses.
• Web. Graphic of expenses.

User Story 2 - Mobile

• Design for mobile. Graphic of expenses.
• Back-end. API for mobile. Graphic of expenses.
• Mobile. Graphic of expenses.

Ill next add the task and stories to a Sprint to track delivery to production :)

[Ilya Lifman]

So what is the difference between task (not a sub-task) via story?

[Matthew Stublefield]

When you first install JIRA Software, the Story issue point has the Story Points field. This numeric field can be used as an estimation statistic on JIRA Software Boards, and if you're using a Scrum board then you can see Story Point info rolled up to the Epic. You'll also see it on various JIRA Software Reports.

You can modify the field context so the Story Points field is available on other issue types, and once you do that, there's really no difference between a Story and any other issue type. I like having different types of stories (so they can have different workflows), so under my epics I have issue types like Course Development and Video.

[Simon Zimmerman]

If I add the Story Points field to Tasks, will any estimations be reflected in the Velocity report?

[Nic Brough -Adaptavist-]

Yes, as long as your "task" issue type is at the same level as Story in the Epic -> Story -> Sub-task hierarchy. 

i.e it is Epic -> Tasjk -> Sub-task

[Mike Howells]

Velocity is supposed to tell you how many sprints it will take to deliver a set of user stories, so you can tell your users/customers when they'll get what they need. So I would only put points on Story issues, not Tasks. 

If you put points on Tasks then the team's velocity does not reflect how many stories they can delivery per sprint, so you can't use it to estimate the number of sprints required to reach a delivery milestone. 

It's important to show Tasks and other things that don't deliver value to users on the team's backlog, but they should reduce velocity not increase it. The team has to make a call as to how much of that "drag" they include in sprints. 

[Adam Robertson]

That's a really weird way to look at it.  Sprint points should be used to gauge an amount of assigned work per sprint, regardless of whether its delivering value internally or externally.  Not assigning points to tasks seems to be breaking a fundamental feature of the process.  If you want velocity on stories, then report on stories and not tasks, but failing to estimate tasks is throwing the baby out with the bath water.

[Mike Howells]

It is a debatable point (groan, sorry) but the way I see it if you put points on all items, even those that don't deliver customer value, then how do you estimate when your backlog items with customer value are going to be delivered?

I'm assuming the team uses their velocity to tell the Product Owner when a set of customer backlog items will be delivered. So the velocity needs to be a measure of how much the team can deliver to customers per sprint. If you include internal team tasks in velocity then you've basically ruled out any future team tasks, because you're estimating delivery dates on the assumption that the team is only working on customer stories.

Bug fixes is another interesting case. I prefer not allocating points to bugs because your giving the team's velocity a boost. Why would you give a higher velocity for introducing more bugs? Bugs actually slow the team down, so having to fix a lot of bugs in a sprint should reduce their velocity, because they'll take longer to deliver the customer value in the backlog. Giving points to a story and then giving more points to the bugs that got into the story implementation seems like double counting. 

So IMHO it comes down to how you are using velocity. If you are using it to estimate when customer stories get delivered then points should only be put on customer stories. If velocity just says how much work the team can do per sprint then delivery estimates will assume the team never works on team tasks or bug fixes, which seems bad. 

[Adam Robertson]

Sure it's debatable, but I don't think you're not delivering customer value per-sprint just because it's not a feature that's immediately visible to them.  Anything you do should be delivering value whether it's releasing a new feature, or improving job processing, or just resolving technical debt so developers can do their job faster (i.e. deliver more "customer-perceived value" faster) in the future.

Regarding velocity and bugs, on my instance we actually don't have an option to assign points to bugs, so there's no velocity boost or "reward" from adding bugs to a sprint.  

Honestly, I think leaving points off of your backend tasks is probably hindering the reporting aspect of this hypothetical project.  If "points on customer-facing items" is a facet you want to evaluate on your sprint, then perhaps you can look at story points delivered on stories, instead of story points delivered on stories and tasks combined.  I think it all comes down to how you set it up, but my main point/opinion is that not counting units of work on backend tasks is, frankly, bad practice.

[Alwyn Pereira]

Adam, Mike, great debate on the topic. 

We have got one item settled. No story points for bugs!

IMHO, the product owner has to understand all the work involved in the making of a product release. If he determines that 'direct customer value' appears minimal, than he can weigh it against technical debt, and occasionally influence decision making to even defer technical dept. Else, you end up with no one being interested in the long term technology evolution of the product and an overemphasis on delivering 'direct customer value'. Its a fine balance.

As a best practice, we tend to clearly state value of technical debt to explain why it has to be taken up now vs later. And we use technical leads as sprint owners, to ensure that sprint owners can effectively influence decision making, as well as have grasp to be able to understand the product owners business perspective, to take/understand the decisions.

Ultimately, finding the balance involves technical folks keeping a fair business perspective and the p.o. keeping a fair technical perspective. Somewhere between, lies the balance!

Velocity has to point to the net additional value the team is adding to the product (direct as well as indirect). 

[Paul Campbell]

Yes, a very interesting conversation.

A couple of points

If you don't assign points to bugs, how do you know the proportion of your team's time goes into this activity? This knowledge can drive process improvements or the adoption of practices aimed at reducing the number of bugs or finding them early.

It's a similar thing with technical debt, how do you make decisions about the risk/value of dealing with technical debt unless you estimate and track it?

Finally, why would anyone think of dealing with bugs as a velocity 'boost' unless they had some perverse incentive to hit a certain number of points in a sprint? If you wanted to game the system you'd just estimate higher to make the numbers look better.

[Adam Robertson]

I would say that whoever created the bug should have to fix it, and they get awarded fewer points accomplished in a particular sprint because they dedicated at least a portion of their time to fixing it instead of enhancing some other feature.  This would hopefully incentivize people to be more careful in their PRs, but unfortunately, would cause some grief when looking at the pre-sprint summary for each user.  If they caused a bug, though, they should be putting in that extra time to fix it ;-)

[Peter_DevSamurai]

Thank you so much for this post! I love the content 

[Oleksandr K_]

Depending on what methodology you are working.
But if you take SAFe then structure would be the following taking @[deleted] example:
Epic: Create Customer Self-Service Portal
Feature: User Authentication.

• User Stories:
  • User Login screen.
  • Forgot Password workflow.
  • ....
• Sub-Tasks:
  •  User Login screen:
    • Design login page.
    • ...
  • Forgot Password workflow:
    • ...

[Kazi Shahin]

[Bryan Wilcutt]

Some Agile to PMI terminology

Epic - Project (PMI): A work breakdown structure (WBS) of a Project.

Story - Sub Project (PMI) or Line Item on the WBS: A subgroup of items or a single item in the WBS related to the same activity.

Sprint - Work Execution (PMI): Work towards a kill gate or milestone.

Scrum - Meeting (PMI):  Typically, this is once per week meeting and not daily since one-on-ones are expected between PM and Team Member on a daily basis.

Velocity - Budgeting (PMI):  PMI uses Earned Value Management which tells you far more information than velocity ever could.

Scrum merely renames things from the Project Management world.  There's nothing new under the sun, as the saying goes, and even PMI is an extension of PM activities from 2,500 years ago (Pyramid construction).

[Nic Brough -Adaptavist-]

"Scrum merely renames things from the Project Management world." - oooh no no no, that's utterly wrong.

You're also wrong about almost all of the parallels you draw.  Story is not far off, but your comparison of Epic, Sprint, Scrum and Velocity are all wildly wrong.  I think you need to have a proper look at the Agile manifesto and Scrum (and the other methodologies it lends itself to)

[Bryan Wilcutt]

I just looked it up, Jan of 2008.

[Rich Hale]

How do you look up the date when you signed Agile Manifesto?   I've tried to, but can't seem to "search", and end up looking through all the various weeks.   Is there a quicker way?

[Bryan]

I just googled "agile manifesto signature wilcutt" and up popped the page with my name on it... Ahh... 2008... memories.  

[Matt Wilkie]

if Agile's 'Epic' equates to PMI's 'Project', then what does an Agile's 'Project' map to?

[Nic Brough -Adaptavist-]

It doesn't, that's one of the reasons the attempt at equivalence is just so wrong.

[Piotr Guz]

I agree with @[deleted] 

"The way I've been approaching the distinctions of issue types is this - I'd LOVE some feedback or alternative suggestions to consider:

• Epic - A general use case that is a collection of features (user stories). (Use Fibonacci numbers to estimate.)
• User Story - Represents a user feature. (Use Fibonacci numbers to estimate.) - 
• Sub-Task - Represents development tasks to accomplish the user story. (No story point estimates.) Generally no more than 1-day tasks. You can either count the number of sub-tasks or time estimate in days in your retrospective to evaluate if your story point estimate for the User Story was accurate and adjust accordingly - assuming you have some velocity history to compare to.
• (Engineering) Task - We used to call these "Dev Stories" (in a pre-Jira project) - represents a set of engineering work that is not directly related to a user story. The team should try to anticipate "Dev Stories" and add them to the backlog sooner than later with estimates (Use Fibonacci numbers to estimate) so the PO can plan milestones."

I can only add:

• User Story - Represents the least portion of business value. Cause the heart of Agile (the roots of Jira are in the agile world) is feedback loop (PDCA cycle). And this loop should be the smallest to split the risk of fail of our work.

best regards

Piotr

Scrum Master

[Christoforos Korakas]

Hello all, 

Jira is a versatile tool that you can adapt to your understanding / way of using user stories 

I really recommend you to read the book User story mapping "https://books.google.be/books/about/User_Story_Mapping.html?id=4YZyBAAAQBAJ&printsec=frontcover&source=kp_read_button&redir_esc=y#v=onepage&q&f=false 

by the person that invented the term Jeff Patton ...

A user story is a way to help the common understanding of a user need for both business and developers ... 

so it needs to be formulated in very specific way to create the needed effect: 

" As a user X (replace X by what the type of user is : guest, member, new ... whatever makes sense / also called personas) I need to be able to do (/find / create - include whatever action is relevant)  Y (Replace Y with the desired think that user needs to do), So that I can achieve Z  (replace Z with the business objective for the user)." 

All questions asked by the developers or users on the story, and the answers given become clarifications and are converted to acceptance criteria (defines when a story is done) 

...

The main issue I have here is that the tools proposed in Jira to do this very important work are nowhere near what the business side people can use to help define these stories ... 

Is it in the plan to offer this some day ? (until then we work with third party tools like stories on board)  

[niladri-bitbucket]

This is not an answer but suggestion.

I have used Microsoft's VSTS for quite some time. And the good part that they have done is to have hierarchy of Epics -> Features -> Product Backlogs -> Tasks/Bugs

Now with Jira, what is being suggested here to use story and tasks as per their intended use which as per the accepted answer is

Story = Requirement

Task = Steps to achieve the story.

Suggestion

Story and Tasks cannot be linked. We can create subtasks but then it does not appear clearly in a hierarchical structure in display which VSTS does pretty well.

If we can have a structure like Epics --> Features --> Product Backlogs --> Tasks/Bugs structure and also their display in hierarchical format, it will be very useful

[Deleted user]

[Sorry somehow saving my edits created a duplicate post]

[Joseph Cheek]

Jira is the only Agile-aware PM software I have used that makes no distinction between a Story and a Task.

[Deleted user]

Use a Jira Subtask for a Scrum "task".

[Eitan Mizrahi]

I am also new to JIRA.

I found it conveniant to declare:

EPICS as the customers (name of customer).

Stories as the progress for each customer.

Task - user handled (not scram) that can break appart the stories into parts.

I create a project (A Goal, that leads to the whole sale for customer, such creating a sales' web-site for the customer, or adding terminals use abilitites, etc.)

When I create the project, and an issue in the jira cloud, I just drag+drop the stroies to the epic, and it is related to the story (in backlog tab, after clicking epic and version on the slide bar).

Version - I am using right now only one version (1.0), but if I enhanced the web-sie, i.e - I will call it the version of my whole product.

[Pamela Ross]

Team,

Thanks for you varied answers to a basic question -- As an Agile practictioner for many years, I too am struggleing to get a consistant glossary of JIRA terms vs Agile terms -- and being able to transition from other tools to JIRA -- (not so simple).

I also am struggleing to uncover how to map deliverable features to components -- which is not a clear mapping -

The tutorials are lacking, as they do not conform to the Scrum Alliance or SAFe descriptions -- which is challenging as I attempt to teach teams about Agile, not just "JIRA"

I will continue to 'troll' the boards here to learn how the JIRA flavor of Agile can work.

[Peter_DevSamurai]

I understand that you’re an Agile practitioner and you’re looking for a consistent glossary of Jira terms compared to Agile terms. Transitioning from other tools to Jira can be challenging, especially when trying to align with Scrum Alliance or SAFe descriptions. While the tutorials available may not conform to these specific frameworks, they can still provide valuable insights into how Jira can support Agile practices. 

Jira Glossary: Atlassian Community has compiled a glossary of Jira terms that covers both basic and more obscure terms associated with Jira.

Agile Tutorials: Atlassian provides tutorials on how to use Jira Software for agile development. These tutorials cover various aspects of agile methodologies such as Scrum and Kanban.

SAFe Implementation in Jira: If you’re specifically interested in implementing SAFe in Jira, there are resources available that provide guidance on how to use Jira to support SAFe practices.

And regarding mapping deliverable features to components in Jira, it might not have a clear mapping as it depends on your specific project requirements and how you choose to structure your components. However, there are resources available that provide tips and best practices for using components in Jira effectively.