Epics, Stories, Tasks, Subtasks… what’s the difference

Epic, Story, Task, Subtask are very common terms to use in issue tracking systems, but often teams form without being aligned on the meaning behind each one and what differentiates one from another. It’s easy to pass over firming up this understanding across the team because, in any moment, actually getting things done seems far more important than agreeing specifically on how we classify our issues.

The key to understanding the difference between these terms is in how we understand what makes a task actionable. Let’s assume that a task is actionable when what needs to be done is clear to the point that someone can do it without questions or conversation. We can experience the difference between these terms if we take this understanding of actionable tasks further and explore the value in a system for collaboratively making tasks actionable.

When we are being asked to do something, we evaluate the request because we first need to decide if we are going to do it. In other words, that we are going to commit to doing it, to hold ourselves accountable to the commitment, and to accept responsibility for having done, or not done, it. Commitments are the currency of trust, so we need to take them seriously.

Committing to tasks before they could be considered actionable is too risky, especially in a team setting. For consideration, tasks come in all shape and sizes:

• Mow the lawn
• Make me a sandwich
• Redesign the website
• Create a time travel device

Tasks are not often actionable right away, so in order to get things done responsibly, we often need to discuss, define, and breakdown the make up of a request so that we can reasonably make a commitment. 

Above, for example and for context, is a diagram containing a Sprint Backlog, which contains items broken down and prioritized to be pulled into the next sprints. In Scrum when the Product Owner works out their list of what the stakeholders want and brings it to the development team, breaking the work down into actionable tasks is the only way to appropriately gain the commitment and responsibility from those who will do the work and hold themselves accountable to doing it.

The terms we are looking to distinguish represent an idea hierarchy and represent the classification that can be applied as we break them down into actionable tasks that, once completed, essentially will make the whole idea a reality. Here is a visual of this hierarchy:

Let’s start with Stories.

Stories contain ideas, and commonly they contain very new ones. The point of a story is its content, not necessarily how the story itself was written or created. When an issue is created and classified as a story, it acknowledges an intended discussion to gain a shared understanding of the ideas contained within it. An issue classified as a story represents the what, not the how, of its content, meaning what the story describes as being desired to be true, but not how it will become true. This is why Stories are estimated with Story Points as it is an abstraction to measure the team’s ability to achieve an anticipated value understood to be from the story itself.

There are a few good techniques to explore when approaching stories with the intention of making them actionable. For example, a good technique is to make sure your story adhere’s to I.N.V.E.S.T:

• Independent means that it doesn’t depend on anything being done first. It can become true on its own.
• Negotiable means that those that want the story to become true need to be flexible with how that might actually happen.
• Valuable means that the story conveys information that surfaces the value within it.
• Estimable means that it needs to be simple and clear enough that it would be reasonable for someone to consider what effort it might take to make it a true story.
• Small stories are typically independent and estimable.
• Testable means that the story is clear enough that it contains within it an aspect that, once real, you could test whether it was the case or not.

If your story is not a good fit for these, a good strategy is to split it into smaller stories. There are a lot of story splitting strategies to become familiar with that help with our effectiveness in these circumstances. Basically, however, a request that is created as a Story type acknowledges that there is probably some splitting and/subtasking needed before commitments are possible. This is important going into planning as it acknowledges there is some teamwork needed before commitments are possible. These are healthy expectations for a team to have when setting out to make big things.

Now, consider Tasks

Tasks, on the other hand, while on the same level as the Story, do not anticipate the same treatment. Tasks are usually self explanatory, but can be reconsidered to be a Story if reasons are surfaced when a teammate is considering committing to it.

Like stories, Tasks represent the What, not the How, but the difference is that they are inherently actionable usually due to a repetitive or simplistic nature of the request. 

A common method for writing Stories follows this pattern:

As a [type of user], 
I want [some goal], 
so that [some reason].

This helps the story meet the I.N.V.E.S.T. story strategy for the reasons described in that section of this article, but not everything needs to be a story. If you are asked to paint a wall blue with some provided paint and rollers, then that task likely does not need a conversation before you can decide to take it on or not. It certainly does not need to be requested as:

As a viewer of the wall, 
I want to see a blue color, 
so that I'm viewing a wall painted blue.

“Not everything is a story” is a big relief for new Product Owners to come to accept.

Subtasks

Subtasks are your smallest pieces of work to be tracked and are a tool for those committing to the parent Task or Story to break their work down further and track how they want to do it. Not all Stories or Tasks need to be Subtasked, it should be up to the team, but if a Story or Task is Subtasked, it should be Subtasked out completely so that when all the Subtasks of a Story or Task are complete, the Story or Task should be able to be considered complete as well.

Epics

Epics are your largest Stories. Really just one up on the idea hierarchy. It goes further, for example, as Epics are the Subtasks for “Initiatives.” See the following image this is even further showing “Themes,” which are a classification of an even larger accommodation for our ideas:

If the above seems appropriate to your team, at enterprise scale, you might consider an add on tool like Jira Portfolio. Most, however, can develop, define, and split Epics in any collaborative documentation, such as Google Docs or Confluence. From there they can create Epics, Stories, Tasks, and Subtasks in their tool of choice.

Continue on to Epics, Stories, Tasks, Subtasks… in Various Tools of Choice ->

Skip to Distilling conversations into ready stories ->

Check out this content’s parent article, Making it work… with Jira ->