In the world of agile development, an “epic” is a user story that’s too big to fit in a production sprint. And that fits right in with our old pal, Homer, whose epic stories like The Illiad and The Odyssey were both long and larger than life.
Now you might say that there’s no place for epics (or Homer) in a Scrum-based development project. After all, you need to split your epics into more manageable user stories so they can fit into sprints, right?
Yes.
And no.
Yes, you’ll need to split your epics into smaller user stories if you want to address those features in your next production sprint. No, because you might not need to do that now. In this article, you’ll see how epics still play an important role in your product backlog.
Why You Need to Split Epics
In commercial software development, an epic usually starts with a top-level task, like “build a payment processing system.” There are many components to such a task, such as creating the customer database, developing user interfaces, and integrating with third-party payment systems – just to name a few.
The problem you run into with epics is that Scrum-based development is completed in short production sprints. At Ascendle, for example, we typically run just two-week sprints.
Obviously, your app development team is not going to tackle everything that goes into “building a payment processing system” in a single sprint. Instead, we split the epic into smaller user stories. Each sprint will include several of these user stories – and our rule of thumb is that no single user story should take up more than 25% of each sprint.
In other words, one user story is the equivalent of no more than a few days of work from our engineers. To get an epic into production, you’ll need to pare off a lot of bite-sized pieces and address it through any number of sprints.
When to Leave Epics Alone
This brings us back to the question of why epics are important. If you can’t work on them in epic form, why not just split them all up front?
The answer lies in a very small distinction. No, you can’t work on an epic without splitting it… but you can work with it much easier. There are two major reasons why you might want to do this: keeping your product backlog manageable and flexible.
Keeping Your Product Backlog Manageable
At the beginning of each new sprint, the product owner will re-prioritize the product backlog based on feedback from the business and its customers.
Now imagine that task if you’ve broken every single epic down into tiny user stories already. The product backlog is going to be so huge it will be difficult – if not impossible – to manage. A list that size can also prove daunting, making your development team feel like no progress is being made. This is in direct conflict with the morale boost your development team should get when completing a production sprint – an important benefit of Scrum.
By leaving large tasks in epic form, it allows your business team and product owner to view what’s left without having to sift and filter through hundreds of tiny tasks. This allows your team to make better choices and comparisons in less time. And even as you start chipping away at an epic, leaving the remainder in epic form is important when communicating with the business.
Keeping Your Backlog Options Flexible
Some epic stories will simply never be prioritized by the business. Maybe new strategies cause you to shift away from them, or new technologies open up better alternatives.
So why waste all that time figuring out how to break each epic down into “bite-sized” pieces, if ultimately you may not have to?
Ascendle’s founder, Dave Todaro, affectionately calls this the “YAGNI” principle. It refers to all those high priority items the business thinks they need at the outset but never turn out to be as important as they thought. What does YAGNI stand for? You Ain’t Gonna Need It. And it happens far more often than most businesses would like to think.
YAGNI represents real time and money down the drain because you expended effort on initiatives that were never really necessary. Like the time and effort spent figuring out how to split an epic that never makes its way into the product.
When should you start splitting epics? Only when you need to. When those features are prioritized near the top and are on your project team’s radar – that’s when you should start thinking in terms of smaller, sprint level user stories.
Why Would Homer Envy Your Epics?
When you first hear the word “epic” you might naturally think of Homer. Even people who don’t recall his name will think of “that Greek dude who wrote long poems about the Trojan Horse and stuff.”
Generally speaking, Homer is considered one of history’s great masters of the genre.
So why would a literary giant like Homer like your version of an epic better?
Because your epics are short. They’re to the point. And while they do take some thought to construct, they don’t take long to write.
Think of how much time Homer would have saved in writing it (or how much time you might have saved reading The Odyssey).
And that’s exactly what you’ll be saving your development team when you leave all those non-priority stories in epic form: time.
