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?

[Phill Fox · Accepted solution]

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.

[vbradberry]

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

[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]

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?

[Chris Kornblatt]

@amirpervaiz086 -- I came here looking for an answer to the same question: "when to chose a  'Task' (not sub-task) versus 'Story' when they're at the same-level in jira"

The way I've been using them as a TPM of a squad:

Story - use story that creates incremental value for the customer (as everyone else has explained above ^^)

Task - involves work on something not directly related to implementing a feature but should be done. e.g. research spikes, change access tokens from person (initial dev) to corporate account, etc.

I still haven't found my answer. Scrum.org is also vague about this. My squad members have also used task & stories in this way at previous companies, so we're moving forward. Hope that helps!

[Deleted user]

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.

[Sundaramoorthy Natarajan]

This make sense than the lot :D

[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

[liz]

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

1. 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
2. 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.
3. 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:

I hope that helps!

[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.

[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.