It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

What is the difference between a story and a task

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?

4 answers

1 accepted

13 votes
Answer accepted

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.

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

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 !

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

Like # people like this

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

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?

Like # people like this

@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!

Like # people like this

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.

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

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you