Agile Story vs Task: how to use them
If you are doing agile software development, you’d have heard of stories and tasks. There is some confusion about these entities, though. What the difference between them is, when to use which. And how they fit into frameworks like Scrum. Or tools like Jira. This article will clear all of that up. So you’ll know all about them and how to use them.
What is a story in agile
The term story in agile means “user story” (usually). User story is an old concept from Extreme Programming (XP). Which has been around for a damn long time (the mid 1990s).
A user story is a simple, natural language description of a software feature or behaviour. And it is described from the user’s point of view.
So instead of talking about the components or interface features, we talk about the user. What they are trying to do, and what benefit they will get out of it.
So where a specification might say “there is a page with a form there and a button here and when submitted it invokes that service call”. We would instead say something like “As a user, I want to search for available flights, so I can pick a flight for my trip”.
We aren’t specifying anything up-front about the implementation. Because in agile, we leave those details until later. Ideally, the “last responsible moment”. We want to talk about and plan out features. But in terms of customer journeys, or business value. Not technical tasks or software components.
User stories usually have a name (“Book an available room”), a description (“As a user, I want to book a room, so I reserve accommodation for my trip”), and some acceptance criteria. These define the exact behaviours that we can test for, to know we’ve done the story.
In the olden days (i.e. the 1990s), user stories might have been written on post-it notes. Or index cards. These days, people are more likely to use a digital software tool. Like Jira or Rally.
What is a task in agile
They might sound the same. But a task is actually very different. In agile software development, a task describes some work. So when a user story is put into a sprint, the team needs to start thinking about how it will work.
They have understood the requirements (in the user story). But now they need to define the implementation. And that is where tasks come in.
To achieve the outcome of the user story, some work obviously needs to get done. So tasks are used to track the work.
They should talk about implementation. The components, services, features and elements that deliver the story.
So they are very different! User stories talk about behaviour, value, outcomes. Tasks talk about work, components, implementation.
There is another way to think about this. User stories are the “what” and the “why”. Tasks are about the “how”.
When to use Story vs Task in Agile software development
I think stories and tasks can both have a role to play in agile. Well, I’ll clarify that a little.
You definitely want to have user stories. It is hard to do agile without some user stories. You may or may not want to use tasks. Remember, user stories are for behaviour. What the system can do, what outcomes it achieves. Tasks talk about how we are going to get there.
You might be thinking “but we must always need tasks to do the work to achieve the story!”. Well, you don’t actually need them. You do need to do the work, but you don’t need to track it with a task. You can just track it with a user story. That is really the key part.
Instead of creating tasks, you can just do the work! And close off the story once all the tests / acceptance criteria have passed.
Why you might want to use tasks in agile
So why would you want to use tasks? You might want to if:
- you have big and complex stories that have moving parts. And different people will be working on them at the same time. (Though I would suggest breaking them down!)
- you are required to track work on different projects or products. That is, some managers want to know how much work is being spent on this versus that. Though you could probably just track work on separate stories.
- you have developers who like creating tickets in Jira and tracking everything (like agile metrics) to the nth degree! Personally I want less tickets and tracking, but not everyone is like me.
Those aren’t all very convincing reasons. So have a think about whether you really need them. Or if you are better off tracking stories.
Story vs Task in Scrum
So in Scrum, the difference is pretty clear. Stories are a form of PBI (Product Backlog Item). But just one form of PBI. You don’t need to use user stories. And your Product Backlog can have other things in it. Bugs, enhancements, technical debt, etc.
So user stories can be pulled into a sprint. To complete the sprint backlog (the plan for doing the work), the team might create tasks. Which define in detail how the work is to be done.
This is what the Scrum Guide says about Sprint Planning:
For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers.
So tasks are something you create when decomposing a product backlog item (possibly a story) in sprint planning.
Again, they are not mandatory. The guide clearly says: “How this is done is at the sole discretion of the Developers”.
So creating tasks or not is up to you. The word “task” does not appear once in the Scrum Guide!
Story vs Task in Kanban
What about Kanban? Well, Kanban doesn’t talk about user stories. That doesn’t mean you can’t use them, of course. Kanban is all about the flow of work and the rules and principles around moving it across a board. It is applicable to any domain so doesn’t talk about what goes in the backlog or how it is defined.
So that means you could put user stories onto a Kanban board. If that is how you want to describe the work to be done. You could also split those into tasks, like in Scrum.
But Kanban doesn’t have a Sprint Planning event. So when would it happen? Again, Kanban doesn’t prescribe rules around this because it doesn’t have stories or tasks.
But if you were going to do it, I would do it at the “last responsible moment” (a Lean principle). Which would be when the user story is moved into the In Progress (or similar) state.
User story vs task in Jira
Since Jira is the most popular tool for agile software development, let’s look at how this works.
User stories are a type of Issue in Jira. They can belong to a parent Epic (although they don’t have to, they can stand alone). There are other types of issues, like Tasks, Bugs, etc. If you are wondering what is an epic in agile, that’s a story for another day. I have an article in the works on that so stay tuned!
Story vs task vs subtask
You can attach child sub-tasks to issues. So you can have an epic with stories, and tasks, and bugs. And those can have sub-tasks attached to them (or not).
This diagram explains the taxonomy of these issue types in Jira.
I don’t love sub-tasks in Jira. But some people do and love them. So it is really up to you.
Summary
So this article has cleared up the matter of agile: story vs task. Hopefully you can see the difference and when to use each one. Do you have any questions or comments on this matter? Or a different understanding of these two entities? Please let me know in the comments below. I will read and reply to every one!
