Before you Scrum, make sure your user stories are not epics

Planning a Scrum sprint requires analyzing and understanding the requirements well enough to be able to split them in small chunks of functionality.
User stories are short and to the point. They can be completed with a reasonable amount of effort (and usually within a reasonable amount of time, too!). They are catalyzers of communication between all the implied parties.

Whether you Scrum or not, I’m sure I don’t have to convince you on the usefulness of refining the scope of your project with the help of user stories.

My epic’s in your sprint!

As most of you already know, epics are… slightly bigger than a typical user story.
Although they might seem short and to the point at first, there is more to them than meets the eye: they actually regroup many stories, hence many distinct functionalities.
They are great to label a set of desired behaviors that are not fully specified, so that you can come back at them later and identify their implications in terms of features to implemented. The problem happens when an epic is planned for a sprint, before it had the chance to be refined.

To put it simply: an epic in a sprint backlog is a hideout for unexplored user stories that will add an unexpected amount of work to the sprint.

Bad for estimations

Epics are hard to estimate.

We know how much time it takes us to walk go to the nearest toilet, but it’s harder to know how much time it takes us to drive to the nearest airport, right?
Epics are your “airport“: a long journey. So their estimation will be hazardous at best.

At worst, your epic estimation is treacherous: when the hiding user stories emerge, you will most likely realize that you have underestimated the amount of effort to provide. That epic will most likely end up taking many days or even weeks to complete. You know that feeling… it’s not a nice one!

Bad for the definition of “done”

Epics are hard to finish because it’s hard to define when they can be considered as “done“. It really amounts to define when all of the epic’s underlying user stories are “done”.

Furthermore they can also become a source of impediment when they imply a feature that won’t be or cannot be implemented until later in the project. “No problem” I hear you say, “I’ll just mock the missing bit”. That’s all great, but you’ll still have to replace that mock with a real integration later on, which means that… you’ll have to write a user story to remember to do that!
As such epics can become a source of friction when the team goes “But I thought we had implemented that feature in that story three sprints ago” – “yes, but that did not include this bit because we had not specified it yet!”. Hilarity ensues… No, actually it does not.

Bad for the burn down chart

Since epics are harder to complete, they end up lingering from one sprint to the other. They break the burn-down chart by making it look like the team hasn’t performed, when in fact they did: they simply could not finish the many user stories hidden by that epic!

Speaking of which, and on a personal note: whether you consider burn down charts as an essential aspect of Scrum or as an agile anti-pattern, there’s one thing I think they are really useful for. Yep, detecting epics. When you get those huge stairs in the chart, which eventually catch up with the ideal effort guideline, it is really saying that the team is handling an epic: you got a 3 or 4 day period with no progress and then the story is competed. A long, horizontal line that finally drops after remaining flat for all that time…

And so?

Well, I’m a pragmatic fella. I don’t pretend I fully master all the concepts behind the Scrum methodology, but it looks to me that before applying a set of rules by the book it is best to master the small tools that help us daily, and make sure we understand their objective.

The objective of well-written user stories is to help us understand an objective, plan the necessary work and keep our effort in focus. Until they are refined, epics go against that.

So before asking a team to Scrum, it might be better to make sure they can write user stories instead of epics.

Then again, this is just my sincere, humble opinion. So if you want to debate on this, feel free to vent it out in the comments here below!



Leave A Comment

Please be polite. We appreciate that. Your email address will not be published and required fields are marked

This site uses Akismet to reduce spam. Learn how your comment data is processed.