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.
If you hang around agile developers, you’re bound to hear the term epics 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. However, it may also be an epic simply 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 eight 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 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!
Examples of Epics and User Stories
It can be helpful to see some concrete examples when trying to distinguish epics from user stories. Consider the following epic:
“As an online customer, I want to be able to save items to a wish list so I can purchase them later.”
This epic captures a large feature but provides little actionable information for the development team. To make it usable, the product owner would break it down into smaller stories:
- “As an online customer, I want to be able to click an ‘Add to Wish List’ button on product pages so I can easily add items I may want to purchase later.”
- “As an online customer, I want to be able to view all items I’ve added to my wish list in one place so I can see what I may want to purchase later.”
- “As an online customer, I want to be able to remove items from my wish list when I no longer want them so it accurately reflects what I may purchase.”
You’ll notice these stories focus on one specific need or action the customer wants to take. This makes them small enough to implement while still delivering value to the end user. The original epic, while very large in scope, provided the framework.
Start With Epics Before User Stories
When you first start planning a product development strategy, 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 the job of prioritizing much harder. Second, the time it would take to write and discuss all those user stories would be like 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.
Why Incremental Breakdown of Epics is Useful
There are several key benefits to only breaking epics down as they move up the priority list:
- Minimizes waste: By not overly investing in lower-priority stories that may never even get worked on, you avoid wasted effort in specification and design. This frees up your team’s time.
- Embraces change: Complex initiatives often change over time. By delaying story breakdown, you can incorporate later learnings without creating complex dependencies that require rework.
- Maximizes value first: High-priority epics with the biggest ROI can be worked on immediately without waiting for exhaustive specifications on all features in the product backlog. Lower-priority items can wait until they are closer to the top of the backlog.
Prioritization Considerations for Epics vs. Stories
Epics are ranked based on expected business value once all the stories within them are complete. So the product owner must estimate the total value an epic will provide. Factors like number of customers impacted, revenue potential, and cost of delay come into play.
For example, an epic around a customer referral program may ultimately enable word-of-mouth marketing. However, the product owner must make an informed projection to rank it against other big initiatives competing for development time and resources.
The stories within an epic are then prioritized based on how essential they are to delivering that overall projected value. Critical path stories needed to fulfill the original intent get brought to the top. For example, within that customer referral epic, the ability to invite people by email may be ranked higher than the ability to share referral links on social media. Both add value, but one is considered more foundational.
This way the sequencing of stories being broken out of an epic is based on what needs to get built first for the entirety of the projected epic value to start being realized. Less crucial stories may stay in epic form indefinitely if the ROI dictates it.
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 that should be fleshed out, discussed, and made ready for a sprint.
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.
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.
Deliver Better Products With Speed, Quality, and Predictability
Ascendle helps companies with a team of product strategists and technical experts to provide expert guidance to deliver with speed, quality, and predictability.
Ascendle is different from other companies. We achieve 2-5X increased velocity using proven agile practices and improve productivity by up to 35% over internal teams. We also offer guaranteed results — or you don’t pay.
Schedule an introduction with Ascendle today to see how we can transform your business.
Editor’s Note: This post was originally published on November 12, 2019 and has been updated for accuracy and comprehensiveness.
