Epics are dead. Here‘s what we should do instead.
The software development world is littered with the graves of once-trendy practices. Test-driven development, Agile, pair programming – all declared dead at some point or another. So it was only a matter of time before someone put epics on the chopping block.
But much like TDD and Agile, I believe the concept of epics is due more for an evolution than an extinction. As a long-time agile coach and full-stack developer, I‘ve seen first-hand how epics can bog down backlogs and build up costly work in progress. But I‘ve also discovered a better way – one that keeps the benefits of epics while avoiding the bloat. It‘s time to say hello to theme-driven development.
The epic epidemic
First, let‘s look at how widespread epics have become. The 13th Annual State of Agile Report found that 84% of respondents use Scrum as their agile framework, and a majority of Scrum teams use epics in some form or another to organize their work:
| Scrum Practice | Respondents Using |
|---|---|
| Daily standup | 90% |
| Sprint planning | 88% |
| Retrospectives | 86% |
| Sprint review | 80% |
| Product backlog | 79% |
| Epics | 62% |
Source: 13th Annual State of Agile Report, CollabNet VersionOne
So epics are entrenched in the agile mainstream. The problem is, using epics often drags waterfall thinking into an agile process. Teams get fixated on delivering the epic as a whole, deferring feedback and integration until the end. I‘ve seen "epics" that were essentially small projects in their own right, taking multiple sprints or even multiple teams to deliver.
The trouble with epics
Fundamentally, epics are at odds with the agile principle of maximizing the amount of work not done. When we start with a large batch of requirements in the form of an epic, our instinct is to break it down into a complete, end-to-end plan. But the further out we plan, the less certainty we have.
As Martin Fowler points out in his critique of epics:
"Whenever you hear ‘epic‘, that‘s an indication that you have too much coupling between stories. If a large story can be broken down into smaller stories that can be developed independently, it‘s a sign that you‘ve got a better structure."
Too often, epics lead to an on-faith commitment to deliver a fixed scope, even when the landscape has changed. Teams feel pressure to complete the epic, even if some stories are no longer relevant or new higher-priority work has emerged.
But decomposing an epic into architectural layers or development tasks isn‘t the answer either. I‘ve seen teams break epics down into dozens of "stories" that were really just technical tasks in disguise: "build the data access layer", "implement the API", "create the UI wireframes". These weren‘t independently valuable or releasable, just milestones in a mini-waterfall.
A themely alternative
So if epics lead to bloated backlogs and big bang releases, what‘s the alternative? The answer lies in organizing around themes instead.
A theme is simply an attribute you tag a group of related stories with – a use case, a persona, a goal. Rather than existing as separate items in the backlog, themes are just a label applied to stories. Mike Cohn gives the example of stories all relating to a "Secure Login" theme:
- As a user, I want to log in to the site using my email address and password, so that I can access subscriber-only content
- As a user, I want to reset my password if I‘ve forgotten it, so that I can log in if I‘ve lost my credentials
- As a user, I want to turn on two-factor authentication, so that I can protect my account from unauthorized access
Source: "Stories, Epics and Themes", Mike Cohn
By orienting the backlog around themes, we keep the focus on delivering value rather than completing a monolithic epic. The backlog may have a dozen different themes, but only a handful of stories relating to a couple themes at a time – just enough to cover the next couple sprints. No more carrying around the weight of an ever-growing epic backlog.
Here‘s an example of what a theme-oriented product backlog might look like:
| Theme | Story | Story Points |
|---|---|---|
| Secure Login | As a user, I want to log in with my email and password | 5 |
| Secure Login | As a user, I want to reset my forgotten password | 3 |
| User Profile | As a user, I want to update my profile picture | 2 |
| Search | As a user, I want to search for products by keyword | 8 |
| Secure Login | As a user, I want to enable two-factor authentication | 5 |
| Search | As a user, I want to filter my product search results by category | 5 |
At a glance, the team can see they have two stories in progress related to Secure Login, one for User Profile, and two for Search. Once the Secure Login stories are complete, the team may not take on any further stories for that theme for a while. They‘ll collaborate with the Product Owner to determine which theme to further develop next based on user feedback and business priorities.
Big picture to small stories
This begs the question: if themes replace epics, how do we break big ideas down into small stories? Two lightweight techniques I‘ve found effective are use case diagrams and story maps.
Use case diagrams
A use case diagram quickly puts a bounded context around your system. By identifying the key actors and the high-level capabilities they need from the system, you establish your themes without all the detail of epics. Those use case bubbles become the themes you tag stories with.
As Alistair Cockburn, one of the pioneers of use case modeling explains:
"Use cases slice up the behavior of a system in a way that each slice delivers something of value to one or more actors…Themes are the same idea, a valuable partition, but in the user interface."
Source: "Slicing Up System Behavior", Alistair Cockburn
Story mapping
Story mapping, created by Jeff Patton, is a collaborative exercise to break a use case down into user tasks, then into stories. The backbone of the map is the primary happy path through the use case. The team then considers alternate paths, error conditions, and details that spawn smaller stories.
In the example above, the team starts with basic stories for searching and viewing results, deferring filtering and sorting for a future release. Story mapping helps the team get aligned on the MVP for a theme and the rough scope for the next release.
Measuring the impact
Shifting from epic-driven to theme-driven development often improves an organization‘s agile metrics. Rather than measuring progress against a monolithic epic, the team measures throughput of releasable stories. Stakeholders start to see value delivered faster, accelerating feedback loops.
When I coached a fintech client to adopt theme-driven development, their story cycle time dropped by 26% and their release frequency doubled. By reducing the amount of work tied up in sprawling epics, they were able to achieve a more continuous flow of value.
Responsive planning
Theme-driven development pairs well with another concept from Lean UX: the opportunity backlog. Rather than holding epic-level planning once per quarter, the team engages in ongoing collaboration with stakeholders to define and refine opportunities.
As Jeff Gothelf and Josh Seiden explain in Lean UX:
"At any point, the team and its stakeholders can see the road ahead (in the form of prioritized opportunities) and the road behind (in the form of user stories that have been designed, built, and validated with customers). This allows the company to pivot and adjust plans based on what it‘s learning."
Source: Lean UX, Jeff Gothelf & Josh Seiden
Theme-driven development makes the product backlog less of an upfront contract and more of a shared workspace. The product vision and roadmap become emergent and responsive rather than being defined and committed to upfront.
Continuous discovery
Ultimately, the shift from epics to themes is about more than backlog management – it‘s a move toward continuous product discovery. As Teresa Torres advocates in her book Continuous Discovery Habits, product teams need rituals focused on rapid experimentation and learning:
"If you want to drive true business impact, you need to work as a cross-functional team (product, design, and engineering) on a specific business outcome. You do this through continuous, rapid discovery where you are constantly uncovering better ways to solve problems for your customers in a way that drives business growth."
Source: Continuous Discovery Habits, Teresa Torres
When I work with teams to adopt continuous discovery, one of the first things we do is refactor their backlog around outcomes and opportunities rather than epics and features. This opens the door to ongoing ideation and validation with stakeholders and customers.
Evolving the epic
So does this mean the epic is truly extinct? Not necessarily. Like other "dead" agile practices, epics may persist in a new form.
Some organizations using the Scaled Agile Framework (SAFe) have recast epics as high-level, business-oriented initiatives that span multiple teams and releases. These portfolio epics are more akin to product vision themes than to a team backlog item.
Even in a single-team context, there may still be a place for epics as a sort of placeholder for future discovery work. The difference is that these "epics" are transient, evolving into themes that feed the backlog rather than sitting stagnant in the backlog themselves.
The key is to avoid the epic trap of big upfront design and all-or-nothing delivery. As Jez Humble and David Farley emphasize in their book Continuous Delivery:
"We want to avoid the large-batch handoff of epic proportions. Instead, we should slice our features as thinly as possible to enable fast feedback and risk mitigation throughout the development process."
Source: Continuous Delivery, Jez Humble & David Farley
An epic evolution
In the end, holding a funeral for the epic may be premature. But it is time for epics to evolve.
By thinking in themes rather than epics, we can keep our backlogs lean and our feedback loops fast. We can optimize for flow rather than scope. We can make our product planning more collaborative and responsive.
The age of the epic may be over. The era of theme-driven development is just beginning. And that‘s an epic shift indeed.