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.
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?
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.
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.
Consider the following ideas to help influence good story writing:
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.