What is the difference between Story and Task?

[JoMi]

Good day Atlassian community!

I really tried my best to find out the answer to my question and read all the documentation concerning this topic that I had found! 

As far as I understand:

Both issues: Story and Task

• Have a parent issue: Epic
• Have a child issue: Sub-task

Let's discuss my organization as an example:

Application: Jira Software 

Organization: Web studio

Project: Development of a web site (company managed, Kanban board)

Let the first Epic be: Development of the homepage

Let the child issue be: Development of the header on the homepage

What issue type should I use for the child one and why? Please also provide an example of using the second issue type (opposite one: Story | Task) in the same project!

Thank you!   

[Jaap Stramrood]

You can you whatever is suited for your purpose, but IMHO,

If the work is related to a 'user story', feature, or another artifact in your end-product that you are developing, you would typically use 'Story'.

In case the work relates to something that has to be done, like a chore, job, or duty, you could use 'Task'. Examples are document, test, or review something.

In case the task is related to a Story you can choose to use Sub-Task of a Story.

A 'Task' is not specifically related to Scrum but is still a plannable piece of work so you can use Jira for this.

But again, you are free to use whatever issue type you pick in your company!

[Matthew Bellamy]

One story being worked on by multiple people causes confusion and leads to over-large stories IMO, as does the use of Sub-tasks which I've tended to outlaw in my area. Our teams were creating huge stories and using Sub-tasks for what I would consider a Story to be. The problem is sub-tasks have no ACs so the work only got tested at the end when the (huge) story got finished - perhaps reflecting 2 or 3 weeks' work in total. That's just semi-waterfall.

Taking the INVEST acronym for Story definition, the S (Small) is I think the most important, and I guide our teams to cut their work into 2-3 day (dev effort) chunks wherever possible (it's a bell curve with 2-3 days the median etc), each delivering micro increments of capability to keep the Kanban flowing. In terms of the OP's question about the difference btwn Stories and Tasks: the former need some QA (and therefore ACs) whereas Tasks don't get QA'd. So, if someone needs to independently check the work, then it's not a Task (it's a Story or Bug). Any more than 10% tasks on your board vs Stories then I'd be concerned.

[martin.marques]

I agree very much, with the exception that for me a Task should follow the same flow as Stories where someone else checks that who did the task didn't miss anything.

We actually have a three-step kanban workflow where the story or tasks has to pass through 3 different members, each one signing off the changes/tasks.

[Pramodh M]

Hi @Jo 

Welcome to Jira 🙂

Yeah this is concern for some people when they want to follow the heirarchy

It's not necessary that you follow the same!

For your scenario, Epic and Story Issue are okay.

If Story is large work item, create a sub-task for a story.

For released features, if you need to track the bug associate it with story.

For releasing features use versioning in kanban project

Hope this is clear 🙂

Let me know if you have any queries

Thanks,

Pramodh

[JoMi]

Good day @Pramodh M

Thank you for your reply! So, your opinion is that in my project I don't need Tasks at all and should use the following scheme: Epic -> Story -> Sub-task

But at the same time, I can still use: Epic -> Task -> Sub-task and I won't need Stories at all, am I right? So, you consider that Story == Task? 

And what do you think about this article:

Source (official documentation): https://support.atlassian.com/jira-cloud-administration/docs/what-are-issue-types/ 

I still don't understand the difference between Story (smallest unit of work) and Task (work that needs to be done). It seems and looks like Task describes the bigger volume of work to be done, isn't it?

[Adam Howard]

I think that means that a Story is a thing the users need us to do, and a task is how we break up that work, into whatever pieces make sense. 

Analogy:

Users need the building heated == story

To accomplish that story, we need to do the following tasks:

* pay the gas bill

* turn on the gas line to the furnace

* light the pilot light

Individually, users don't care about those tasks, or who does them. But their story is only going to be completed when all the tasks have been done. 

[ozy cozy]

Personally I never create tasks in scrum, as I remember task can not have story points.

So there is no room for something that you can not measure. I would create tasks as stories so that I can track and monitor the developers' effort during the week.

If I create a story that has multiple task and wait till the end if spring and close that story then what is the point of agile. 

You can give a feature to developer and wait 2 weeks and say  it is done, to me that is not agile.

Example(software deelopment):

  User login: As user I would like to login and see the inventory(traditional way).

 I prefer create one story for:

• UI page/form
• Api connection and mock data submit
• Backend logic to capture, validate and persist data

All above steps can have AC, means testable independently. Also If I can integrate QA testing in each of these stories, testing tickets will be trackable too, failure or success

So this way I am able to see ticket is being closed during week days. 

I practice this probably for around 4 years and we all enjoyed it, instead if using big stories and put pressure on team members. 

The most critical part is, to make small tickets.

Being able to write something like "As .... I would like to..... so that ...", does not mean this is health story.

Thanks

[Kailin]

@ozy cozy , perhaps there needs to be an Admin to help you configure your settings, but a Task can have Story Points as a time estimation. I've seen this done in the past two companies I worked for.

[OliBravo]

According to @Jaap Stramrood : In case the work relates to something that has to be done, like a chore, job, or duty, you could use 'Task'. Examples are document, test, or review something.

Please notice, that user story has its own sense in terms of scrum. So don't try to figure out the difference between US and T only from JIRA definitions, but have in mind the broader context of US. You should typically phrase user stories with the following schema: As <who> I'd like to <do something> to <the purpose of the feature that needs to be implemented>. As You can see, in user stories the business context play an important role. That's the difference to Task which can be understood as a side work, though still relevant to the project/development process.

[Robert Navarette]

Per Mike Cohn...

"A story is something that is generally worked on by more than one person, and a task is generally worked on by just one person."

The Difference Between a Story and a Task (mountaingoatsoftware.com)

[Jim Collins]

I like that definition, but in Jira, it looks like sub-tasks are the smaller units of a story (or a task) perhaps suitable for one person. I think that Jaap's explanation is very clear.