What are the differences between agile epics and user stories? User stories are a fundamental component of any agile development. They are lightweight requirements that represent new functionality that delivers value to business stakeholders; including end users. They’re the building blocks that get prioritized on the product backlog and brought into sprints, and they focus the development team on providing business value.
So what’s an epic?
If you hang around agile developers, you’re bound to hear that term, too, from time to time. And they sound just like user stories. But are they? In this post, I’ll dive into the differences between epics and user stories: what they are, how they’re related, and why you need both for your agile development projects.
What is a User Story?
Previously, I shared an in-depth look at what user stories are and how they’re created.
To summarize, a user story starts with a simple statement in the form of:
As a [role], I want [capability], so I [benefit]
To this statement we add a variety of details, consisting of the acceptance criteria and the development team’s discussion notes.
Once those elements are all in place, the user story is considered ready for production. It can then be included in the next sprint… if it’s prioritized high enough by the product owner.
What is an Epic?
An epic is a big user story. The term is often used to describe incredibly long stories, like Paradise Lost, written by the 17th-century English poet John Milton. Milton’s “epic” poem originally consisted of more than ten volumes with more than ten thousand verses.
As it relates to software development, though, the bigger the story, the more likely you’re looking at an epic. This is the most significant difference between agile epics and user stories.
That’s it. Nothing fancy here. No need to get tied up in knots trying to figure out, “Should this be an epic or a story?” If it’s something that provides business value and needs to be on the product backlog, it’s a user story. But it may also be an epic, because it’s big.
So what does “big” actually mean? In the years I’ve been using Scrum, the best two definitions I’ve found are:
- An epic is a story that is larger than 8 story points
- An epic is a story that can’t be completed in one sprint
I think the second definition is better, since it doesn’t rely on your use of story points for estimation (though you can read why I love story point estimating) and it’s independent of your particular team’s velocity.
Epics can range from user stories that are almost small enough to fit in a sprint, to huge “high level” epics encompassing large features.
Check out my book The Epic Guide to Agile to learn more!
Start With Epics Before User Stories
When you first start planning an agile development project, all of your user stories will likely be in epic form. Then, as the Product Owner starts prioritizing, the most important of those epics will be broken down, down, down into much smaller user stories.
The Product Owner then prioritizes those stories and the highest priority ones will make it into the next sprint.
One of the chief benefits of epics is that they keep your product backlog from getting cluttered. Think what would happen if you broke every single one of your epics down into sprint-sized user stories at the outset of a project. First, your product backlog would be incredibly unwieldy, making your product owner’s job of prioritizing much harder. Second, the time it would take to write and discuss all those user stories would be like… well, traditional project development.
By keeping most of your user stories in epic form, you make it much easier for the product owner to manage the product backlog. More importantly, you keep your development team from wasting their time hashing out a vast number of user stories that might never be prioritized at all. At the start of a project, I like to create a product backlog comprised of 50 to 75 stories ideally, and no more than 100 at the high end.
When to Break Your Epics Down
There is only one appropriate time to break an epic down into sprint-sized user story chunks: when the product owner feels that an epic is nearing the top of the backlog. In that way, the movement of an epic toward the top of the backlog is another difference between agile epics and user stories.
Until that happens, your user stories are better off residing in epic form. But once an epic climbs into the upper reaches of your product backlog, it’s time to start breaking it down.
You don’t need to break the entire epic down into sprint-sized chunks, however. In fact, you shouldn’t. Some of the user stories within that epic are going to be higher priorities than others. And some of the user stories you’ll find within that epic will be much lower than other priorities on your list.
You want to chip away at your epics like a sculptor chips away at stone – not to create something new, but to reveal the important parts hidden inside. As Michelangelo once said, “Every block of stone has a statue inside it and it is the task of the sculptor to discover it.”
So, too, does your product owner need to chip away at your epics to discover the most important user stories inside. Those – and only those – are the user stories which should be fleshed out, discussed, and made ready for a sprint.
And after you chip some user stories out of an epic what happens to the remainder? Nothing happens to it… it remains in the product backlog as an epic. After the next sprint, your product owner may choose to chip out some more user stories from it. Or maybe the epic loses some relevance without those important parts and drops further down the priority list.
Either way, the decision of what to do with an epic will be made based on that epic’s position within the product backlog and nothing else.
Epics and User Stories: A Tandem of Efficiency
So there you have it.
What’s an epic? It’s a big user story that isn’t ready for – and can’t fit into – a production sprint. You store epics in your product backlog because they give you a huge efficiency boost, keeping your Scrum development team away from lower priority distractions.
And when an epic nears the top of your priority list, you don’t need to break the whole thing down. You simply break out as many high priority user stories as you need. Then the product owner prioritizes both the completed user stories and whatever remains of the epic in the product backlog.
In this way, combining epics and user stories creates a tandem of efficiency for your Scrum development team. While similar in nature, epics and their smaller, sprint-sized user stories serve two distinctly different purposes.
If you’ve struggled with realizing business value quickly with your product development teams, contact us today.
