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?
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.
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).
>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
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?
Story -> subtasks
and both can be added in the sprints so what is criteria to choose between them?
@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!
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
It's all new to me but as I understand it thus far there is basically a three level hierarchy:
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.
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":
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:
...and here's a bit about sub-tasks (emphasis on "issue") which again is more clear since we've defined "Issue":
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!
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.
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