Stories versus Themes versus Epics
This article was originally published here by ScrumAlliance.com, in March 2014.
When a new team is just beginning to adopt Scrum the difference between stories, themes, and epics always seem to be a source of some confusion. In particular, where stories end and epics begin tends to be a particular sticking point. In this article, we’ll take a closer look at each artifact to get a better understanding of the subtle differences between them so we can better communicate to our teams when each is appropriate for the work at hand.
Let’s start with a few definitions…
Stories
A story is a self-contained unit of work agreed upon by the developers and the stakeholders. Stories are the heart of Scrum, and the building blocks of your sprint. An example of a story may be…“As a salesperson, I’d like to set my password, so I can log into the system.“
Themes
Themes may be thought of as groups of related stories. Often the stories all contribute to a common goal or are related in some obvious way…such as all focusing on a single customer. However, while some stories in a theme may be dependent on one another, they do not need to encapsulate a specific workflow or be delivered together.
Epics
Epics resemble themes in the sense that they are made up of multiple stories. They may also resemble stories in the sense that , at first, many appear to simply be a ‘big story’. As opposed to a theme, however, these stories often comprise a complete workflow for a user.
But there’s an even more important difference between themes and epics. While the stories that comprise an epic may be completed independently, their business value isn’t realized until the entire epic is complete. This means that it rarely makes sense to deliver an epic until all of the underlying stories are complete. In contrast, while stories comprising a theme are related each is still independent enough to be delivered separately and still provide some measurable sense of business value.
Why stories, themes and epics?
When faced with the confusion between stories, themes, and epics many budding agilistas wonder why we wouldn’t simply choose stories in every case. One of the most common reasons is often the sheer size of some stories.
Stories that at first seem daunting often need only to be broken down further into smaller stories that can be estimated individually. To get a handle on how the story can be broken down, try asking your team some of the following questions…
Why does the story seem so difficult to estimate?
Are the individual tasks that make up the story too complex?
Does the story have dependencies on other work that has yet to be completed, or that must be completed by a third party?
Are there technical or business unknowns in the story that are still unclear?
Once you have a feel for where the hesitation originates from you can take another pass at breaking down the story in the context of the questions above.
An example of an epic
Now that we have a feel for ways in which larger stories can be broken down further, let’s take another look at our earlier example of a story to see if it fits this description.“As a salesperson, I’d like to set my password, so I can log into the system.“While at first this may seem like a fairly innocuous story, there’s actually a bit to unpack here. For example, a few questions immediately spring to mind…
How does the salesperson first access the system to set their password if their account isn’t fully setup?
Do password strength requirements exist that will need to be enforced?
In order to better tackle some of these unknowns the story above may be better served as an epic comprised of the following stories…
“As an Administrator, I’d like to send an email to a new salesperson containing a tokenized access link, so they may temporarily access the system in order to set their password.”
“As a Salesperson, I’d like to edit my profile, so I may set my password.”
“As an Administrator, I’d like to ensure that all salespeople’s passwords meet corporate strength requirements, so I can harden access to the system.”
There are a few things we may immediately notice about the stories above. First, when broken down each individual story paints a deeper picture of what’s actually happening in the system than the original epic ever could. In the least, this may highlight new interactions with the existing system that may increase or decrease the estimates. For example, in story 1 a developer may respond with “we already have a system in place that allows us to send emails” or “our existing email system only allows for plain-text messages without links in the email.” While neither of these situations may have been obvious prior, either may significantly increase or decrease the estimate.
Next, the stories have an implied workflow to them. A salesperson cannot access the system to update their password until they’ve received their initial email. In addition, the salesperson should not change their password before we can enforce its strength. This workflow has an obvious beginning, an obvious end, as well as a few steps in the middle. For this reason it can often be helpful to think of epics as a Story Arc.Finally, although the stories comprising an epic may be completed individually, they provide no measurable business value on their own. Shipping the functionality to email new salespeople provides no value if the profile page or the new password functionality doesn’t yet exist. By the same token, allowing the user to set their password without enforcing corporate strength requirements will result in many passwords being invalidated as soon as those requirements are in place.
Creating epics from stories that are just too big
A related rule of thumb is to automatically further break down any story that is estimated above a certain threshold. A good starting point for this threshold may be where your team has historically tended to become inaccurate with their estimates.For example, imagine that your team’s velocity tends to be relatively predictable when estimating stories of sizes 1, 2, or 3 points but doesn’t have a great track record with stories sized at 5 points and above. If this is the case, then any story estimated at 5 points or above should automatically be broken down further before it's added to a sprint.In addition, breaking a large story into smaller stories has the added advantage that multiple smaller stories will travel the sprint board faster than a single large story. Though the same amount of work may be occurring in either case, the negative effect on a team’s moral as a single dominating story sets in the ‘In Progress’ column for the majority of the sprint cannot be understated. A vibrant board not only helps a team maintain a feeling of forward momentum, but it also encourages stakeholders to take an interest in checking the board each morning to see the progress the team has made.
An example of a theme
While the example above provides a great demonstration of an epic, themes may still be a bit unclear. Let’s look at an example of a common piece of work that can often be represented as a theme—performance tuning.Improving the performance of a specific feature of an application often involves making many small improvements towards the end goal of a significant performance improvement. For example, imagine that your application includes a report to display the total sales numbers per salesperson. These numbers may be calculated as of the previous day.This can be a time consuming report to execute, and as a result the entire application tends to hang for several seconds each time a user runs it. There may be several things we can do to improve this report, which are captured below as stories…
“As a Salesperson, I’d like for the UI of the application to remain responsive while the report is loading, so I may cancel the report if desired.”
“As a Developer, I’d like to pre-aggregate and cache the sales numbers as of the previous day, so they do not need to be recalculated each time the report is ran.”
“As a Developer, I’d like to generate the HTML table containing the sales numbers on the server and send it pre-rendered to the client, so it no longer has to be rendered by JavaScript on the client.”
Each of these stories has the potential to improve the performance of the report. However, while each story contributes to the same overarching goal they do not need to be completed in a specific order. Furthermore, each story could be delivered independently from the others and still provide some measurable benefit to the end user.For these reasons these stories are best grouped into a theme rather than an epic. Grouping these stories by theme allows us to see the broader goal that each story contributes to without forcing us to approach the stories in a specific order. Also, grouping the stories as a theme also negates the need to hold delivery of the entire group until each story is complete. This give us more flexibility in scheduling and planning as well as in our ability to add and remove stories as the shape of the backlog changes.
In closing
We’ve taken a closer look at each of the Scrum artifacts of stories, themes, and epics as well as dove into the strengths and weaknesses of each. In addition, we've looked at examples of using each type of artifact in practice to better illustrate when it may be the appropriate choice for a situation.The choices of stories, themes, or epics bring an incredible amount of flexibility to a Scrum team. This flexibility can be realized not only in the creation and grooming of the backlog but also into the planning of each sprint. As a result of having a clear understanding of the differences between each artifact, as well as the flexibility to choose the right vehicle for each situation, teams can dramatically improve the accuracy of their sprint planning sessions. This increase in accuracy can greatly improve the perception of a team’s success in the eyes of stakeholders, which can go a long way to improving their overall odds of success when adopting Scrum.