Before You Scrum, Make Sure Your User Stories Are Not Epics
Keeping your user stories short and simple is key to effective scrums and feature implementations.
Join the DZone community and get the full member experience.Join For Free
User stories are short and to the point. They can be completed with a reasonable amount of effort and 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!
Epics might seem short and to the point at first, but 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 bedecomposed into user stories .
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”
It’s hard to define when an epic can be considered as “done“. It really amounts to define when all of the epic’s underlying user stories are “done”.
Epics 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, and so… you’ll have to write a user story to remember to do that!
As a consequence, epics can become a source of friction:
“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 take more effort to complete, they break the burn-down chart by making it look like the team hasn’t performed, when in fact it 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: 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…
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 write user stories instead of epics.
Published at DZone with permission of Diego Pappalardo. See the original article here.
Opinions expressed by DZone contributors are their own.