User stories: A tale of epic confusion

In a case of Semantic Diffusion, the original definition of ‘epic’ has weakened over the years. My observation is that epics either help or hinder good story writing depending on how we use them, and how well we understand what good user stories look like. In this article, I’ll explore why epics used in certain ways lead to different outcomes, and what you might do instead.
​

Good user stories

Before we get into epics, we need to talk about ‘user stories’. The incremental breakdown of work that user stories yield is essential to agile software development and continuous delivery. Yet they are notoriously hard to do well. Good story writing takes discipline and practice. Good user stories follow INVEST: Independent, Negotiable, Valuable, Estimable, Small, and Testable. Small and Valuable are arguably the most important, yet also the hardest to do well. Key to Valuable is another V — Vertical. ‘Vertical slicing’ refers to cutting through each layer of the application to deliver value, as opposed to horizontal slicing, which focuses on one layer at a time.
 

 

Story writing is a team effort, yet you might ask yourself, “how many members of your team are skilled or even interested in writing good user stories?” Developers just want to write code! If we want good user stories, we need to make it easier to write good ones, and harder to write poor ones.

Mike Cohn introduced epics in his seminal book, User Stories Applied back in 2004. In User Stories, Epics and Themes, he describes an epic as: just a label we apply to a large story. In other words, user stories are discovered to be epics through sizing.
 

 

Generally speaking, a user story we consider “large”, or “too large” means we lack confidence in developing in its current form. When writing user stories, we don’t know whether they’re right-sized for development until we size them. Does your team have rules about stories being too large? Does your team say, “13 points is too large” or, “XL is too large”? Calling these out as epics helps to emphasise the need for story splitting. Is this how your team uses epics today?
 

Epics today

These days epics are commonly used to group stories, often for reporting purposes. Perhaps the product owner is reporting to a product manager and grouping stories into epics has become an easy way of reporting progress at a higher level.
 

Writing small user stories is hard, especially when we’re aiming for “very small” (e.g. cycle time of 1–3 days). In this case, most stories probably start out as epics. Calling out a large user story as an epic helps to emphasise the need for story splitting. But it doesn’t work very well when an epic (large user story) belongs to an epic (group of stories).

It goes without saying that this is confusing, so teams pick the definition that suits them. My observation is that teams use epics to group stories. Using epics to group stories deprives us of a concise term that could otherwise be used to emphasise the need for story splitting. Why not simply choose another word to describe a group of user stories? How about ‘feature’, or ‘milestone’? What’s stopping you?

Does your team use Jira? The appeal of Jira influences the grouping of stories into epics for reporting purposes and fuels a need to have every story assigned to one. Have you ever wondered what drives the questions, “what epic does this story belong to”, or “should we create an epic for that”?
 
When lacking awareness of what good user stories look like, this approach leads us to write poor user stories. Using epics to group stories can be an impediment to vertical slicing. Examples of such epics include ‘Infrastructure’, ‘Monitoring and Alerting’, ‘Front-end/Back-end’, ‘Integration’ to name a few. These epics encourage ‘horizontal slicing’, which is exactly what we don’t want! Vertically sliced user stories should be incorporating elements of each of these to be considered done.

Ironically, epics that encourage horizontal slicing are not all that effective at reporting progress. For example, why and how would you estimate and track progress toward ‘Security’? Do you really want to be reporting that Story X is “done” but not releasable because it depends on Security Story Y which is not yet done?
 

Process comparison

Let’s compare the process potentially influenced by the two uses of epics (e.g. purely as a large story versus used as a grouping mechanism) using a contrived example of a user changing their password with an email notification.

Epics used to group stories:

1. Epics are created either upfront before any stories are written, or by grouping existing stories. Some of the epics will unwittingly impede vertical slicing, e.g. ‘Front-end’, ‘Back-end’, ‘Security’.
2. Stories are written to align to the epics, or new epics are created to group the stories. These stories are less likely to be vertically sliced, and would probably be better described as tasks, e.g. “Change Password UI”, “Change Password API”, “Authorise request to Change Password”.
3. During story sizing, stories/tasks discovered to be too large are decomposed, further impeding vertical slicing, e.g. “Integrate with email service”. 
4. Not all tasks are completed by the next reporting cycle. Progress is reported against each epic, even though no working software has been delivered to customers.

Epics used to describe large user stories:​

1. No epics are created upfront.
2. ​Stories are written uninfluenced by epics. These stories are more likely to be vertically sliced. The acceptance criteria would assume the need for UI, API, Authorisation, integration with email service, etc.
3. During story sizing, stories discovered to be “too large” are called out as epics, and are decomposed whilst preserving vertical slicing, e.g. “Change Password email notification” is extracted as a new story. 
4. Not all stories are completed by the next reporting cycle. It can be reported that “Change Password” has been delivered, and “Change Password email notification” is in the backlog to be prioritised.
   ​

Conclusion

Consider the following ideas to help influence good story writing:

• Epics are not an essential concept to user stories or agile software development. First ask whether they’re needed at all.
• Refrain from creating epics upfront. Even with best intentions and a good understanding of user stories, it’s hard to predict what kind of influence they’ll have on story writing. Jeff Patton’s User Story Mapping may help here.
• Discover epics through story sizing. When a story appears to be too large, emphasise the need for splitting by calling it out as an epic.
• If epics are being used to help manage a large backlog, ask whether the backlog really needs to be that large. Mike Cohn’s Four Steps to Keep Your Product Backlog Small and Manageable may help here.
• If for some reason it is necessary to group stories, ask whether a different or more accurate term can be used. e.g. feature, theme, milestone.
• If epics are being used for reporting purposes, ask how the reporting is being used and whether it is valuable and necessary. Are there alternatives?
• Understand how software tools such as Jira are influencing team processes. Should they be allowed to evolve independently of a software tool, or be constrained by it?