nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What is the difference between a story and a task

vbradberry

I use a Kanban board and for the issues that I have been creating, i have been assigning my issues to be tasks, but am now questioning whether or not I should be making them stories instead.

So my question is, what is the actual difference between a task and a story? Is there any real benefit of using one over the other?

Accepted answers

Phill Fox

At risk of stating the obvious the difference between a task and a story is whatever you determine the two issuetypes to be used for.

Having said that there are some common examples of differences that can help you phrase the decision.

A story is often written using a standard format such as "As a <role>, I want <feature> so that <reason>."

with possible expansion then beyond the simple statement.

Whereas a task might be something more along the lines of "Undertake review of CI build agent usage".

The benefit of having the different issue types allows you to handle the expected workflow in different ways. The split between story and task can go further for example you could have different issue types to distinguish items that are related to technical debt, potential change requests, performance testing, etc. etc. It all depends on how you want to handle the workflow and describe the activity.

All comments

Phill Fox

At risk of stating the obvious the difference between a task and a story is whatever you determine the two issuetypes to be used for.

Having said that there are some common examples of differences that can help you phrase the decision.

A story is often written using a standard format such as "As a <role>, I want <feature> so that <reason>."

with possible expansion then beyond the simple statement.

Whereas a task might be something more along the lines of "Undertake review of CI build agent usage".

vbradberry

I suppose my issue was relating more towards what is commonly used by others since the issue types are in fact, mostly arbitrary.

unknown

As you note, in JIRA the difference is only what you say it is...

That being said, what distinguishes a Task from anything else in our shop is that there is no QA, UAT, or release steps required and actual deliverable(s) are optional.

So.... It is Created, To Do, In progress, Done. Simple work flow, No QA, Deliverable(s) optional.

Hope that helps.

Tarang

A story is one that requires a number of skills coming together to compose the outcome. Thus it is composed of multiple tasks, likely to be fulfilled by multiple people on the team working together for the outcome.

A task (sub-task), is a smallest decomposed step into fulfilling a story, which requires a number of steps. Sure you can have a task to perform that is not necessarily bound to a story, though I often contest this should be the first task of the first story that needed this to have been performed. For example "Order equipement".

If you are familiar with UML, then I reason the following:

Epic - (akin to chapter in a book) is one where you have many actors, who take at least one or more actions in order to achieve one or more outcomes for the actor.

e.g Going on vacation

Story - Is one where you have single actor who takes at least one or more actions in order to reach the single desired outcome.

e.g going to the airport and catching a flight to your vacation

Task - is one where a single actor takes a single action with a single output

e.g calling Lyft to take you to the airport

I reason this as I often come across teams where everyone is talking about any work in terms of tasks, and thus missing to draw on the senses within the team regarding the levels of complexity/uncertainty corresponding to the item.

Metaphor: Task is akin to being a petal in a flower - that tells the full story !

Guillaume Cote_o1ascx

Hi Tarang Patel,

Thank you for your explanation. I still have a question about the "hierarchy" you describe between stories and tasks. When you say :

"A task (sub-task), is a smallest decomposed step into fulfilling a story, which requires a number of steps."

Do you suppose that task and sub-task are on the same hierarchy and their parent is story like : Epic -> Story -> Task, Sub-task? If yes what is the difference between Task and sub-task?

From what I read, I believe it's more like : Epic -> Story, Task -> Sub-task. Thus, a story can be decomposed in a bunch of sub-tasks but not in a bunch of tasks? (and a task can be decomposed in a bunch of sub-tasks too).

Tarang

>Do you suppose that task and sub-task are on the same hierarchy and their parent is story like : Epic -> Story -> Task, Sub-task? If yes what is the difference between Task and sub-task?

No, not really. Epic -> Story

-> Task

-> Bug

It is best to be explicit and reason with Why? choose this hierarchy over another in your organization. As having alignment will alleviate headaches downstream.

amirpervaiz086

Hi @Tarang your answer makes a lot of sense as I understand Task and Story are more contextual terms and could be used according to your project need.

However, I am still a bit confused about choosing 'Task' Vs 'Story' as they are both at the same level in JIRA and we can also treat Task as Story when further subtasks can be added inside each Task so how do you choose one over another?

For instance:

Story -> subtasks

Tasks->subtasks

and both can be added in the sprints so what is criteria to choose between them?

Tarang

I am sorry if I added to the confusion. In truth the confusion in terms is due to how I suspect Atlassian evolved Jira. It really was a bug tracking tool that evolved for managing work and flow of work for agile teams. So the hierarchy of Bugs, Task and Sub-Task was likely the starting point.

I imagine, IMHO there was probably poor consideration given to the fact Story & Task appear at the same level in the hierarchy and as far as human dynamics of change management goes for adoption of the tool every team in every organization will go through this conflicted view on such a hierarchy. I here this issue often and any time a new person joins a team they have to at some point go through this conversation - ground hog day!

@Chris Kornblatt has summarized it best in terms of which one to use and when. Though there is no reason to expect Scrum.org or Scrumalliance.org to have an opinion on this, as its how Atlassian has chosen to express this.

One can see why they may have decided the way they did, as if you wanted to express work that wasn't part of value creation and needed to be performed then having the Story->Task hierarchy would mean you'd have to create a story to express such work.

Personally if I was the PO on this product, there are lot of things one would have gotten rid off, such as Sub-Task while making a Task as the smallest atomic component of work in relation to value creation and introduce the noun "Chore" to assert work that @Chris Kornblatt states above

Trey Williamson

This would all be made easier if Atlassian allowed Tasks to be children of Stories in the same way that subtasks are children of stories.

Jira's hierarchal structure is often at odds here with agile best practices.

liz_fi2nj9

It's all new to me but as I understand it thus far there is basically a three level hierarchy:

Level1 - the highest level group, named Epic, may be the responsibility on one person but completed by many people if it contains Level 2 items
Level2 - member of Epics, if you use them, named Story or Task or Bug, may be assigned to one person and may be completed by many if it contains Level 3 items.
1. Only this item moves through the board columns.
2. If you create new Issue types they are basically level 2.
Level3 - the to do list of a level 2 item named Sub Task, can only be assigned to one person

The fact that Jira has used some terminology to name these items that is confusing is unfortunate - I happen to think using the term 'Issue' is also a problem but we quickly understand that it doesn't mean 'problem' it mean something more general - but as said previously it's a result of where Atlassian they came from, so...

I think if we can separate the 'label' from the 'item' it's more understandable even though it may be annoying. I would have liked to have seen something like my list above (assuming I have it right) in an introductory guide or video, it would have helped me greatly.

mycahmason

Jira makes it difficult to sort all of this out since it doesn't define the terms very clearly in one place, but the main thing to understand is how Jira defines "Issues":

In Jira Software, we call work items like user stories, tasks, and bugs "issues".
Scrum Tutorial (Step 2)

Also, Issues (Stories, Tasks, & Bugs) should be estimated. This part is a little confusing since the field in Jira for estimating is "Story Points" (maybe it should say "Issue Points"?). But now that we know the definition of an "Issue", it makes the following more clear:

Estimate Your Issues: Estimating issues in your backlog helps you to predict how long portions of the backlog might take to be delivered.
Jira Issues Tutorial

...and here's a bit about sub-tasks (emphasis on "issue") which again is more clear since we've defined "Issue":

A sub-task can be created for an issue to either split the issue into smaller chunks, or to allow various aspects of an issue to be assigned to different people.
Creating issues and sub-tasks

It is also important to understand why we need/use a Tasks (and that they are distinct from Sub-tasks). Since not every piece of work we do during an iteration/sprint comes from a User Story (Story) and it wouldn't make sense to create a Story for the work, we have the Task. It is similar to a Bug; it wouldn't make sense to create a User Story for a bug since it is not a feature being requested. Similarly you might have work to do that is not a Bug or part of a Story but still needs to be accomplished during the iteration/sprint (e.g. refactoring or tech debt) so you should use a Task.

Based on that and some other research, here's a graphic I put together to help solidify the hierarchy:

Jira Issues Hierarchy.png

I hope that helps!

Sundaramoorthy Natarajan

This make sense than the lot

Tarang

Unfortunately the fact that these structures are all at the same hierarchy level, Story/Task/Bug, then when it comes to Story/Task it only adds to the confusion of use and adoption.

If the intension is to help people differentiate between User facing work and Infrastructure work then it would have better to define the artifact with such a distinction and possibly in attributes too.

Spoken language matters as Task & Sub-task confuse the space and prolong the adoption if not look out for simpler solutions.

In absence of this

>Since not every piece of work we do during an iteration/sprint comes from a User Story (Story)

Arguably work that isn't for the purpose of delivering value to the customer should be questioned. So I contest that all work that is needed to deliver value can be framed as a User Story - as empathy with the user in mind is likely to guide developers of solution to one that befits the need and design simplicity for use.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software

jira-administration

task

sub-task

story