Who remembers loving High School English? Anyone…Anyone…. No I didn’t think so. But we all remember it very well. One of the things that really stands out for me was the number of really, really, really long books we were forced to read and somehow try to like. These giant books were called…Epics. Apparently we all loved them more than we were willing to admit, because epics are becoming an ever increasingly vital part of any agile planning process. This is a dangerous trend, and we need to be sure we are looking at this clearly and carefully before we end up re-creating the waterfall, just with fancy new names.
So what is an epic, and how did it reach this exalted status? Well, in the early days, we would run across a story from time to time that was just clearly too big for a single iteration. In order to articulate how big these stories were, we gave them the special name “Epic”. The advantage of such a name is that it calls out two major points about the story. The first point is that it is huge. Way too big to be taken on all at once. The second part is that it can be broken into more digestible chunks. “Ok kids, we are going to read chapters one through six this week. And there WILL be a quiz.”
The parallels with real epics take us very far. The epic as a literary device is a collection of stories that, when taken together make up a much larger story. Some of the more famous epics take on such heady topics as the founding of Rome, or the Trojan War. They are also supposed to be in verse, but lets skip that part. The other important aspect is that each story really does stand on its own. And this is where I think we are going wrong with epics in Scrum. Many teams are starting to use epics as a way to avoid the hard work of creating a story that is small enough and yet adds value. If we can identify something as an epic, we now can see it along the lines of a miniature project, with timelines and planned completion dates. Each story can become part of the work breakdown structure. Now, if only there were a convenient way to track these epics, maybe with a Gantt chart, we would be golden.
What should we look for in our stores that make up an epic then?
- Size – A story needs to be small enough to fit into a single iteration. If we as a team aren’t sure, then it is better to find a way to make each story smaller until we are sure.
- Scope – Let’s borrow from the object oriented principles of good design. The Single Responsibility Principle states that a software construct, like an object or method, should do one thing and one thing only. This should be true of a story as well.
- Independence – Just like those ancient epics, a story must be able to stand on its own. I am seeing a lot of people start to fit “technical stories” into their epic breakdowns, because now they can simply say “sure there is no identifiable user value in *this* story, but it still contributes to the end epic, and that is all that matters anyway”. Thus we see the demise of that beautiful concept: Potentially Shippable Functionality.
- For an excellent deeper look into breaking down User Stories, go to Bill Wake’s post: “20 Ways to Split Stories“
I am not suggesting that epics don’t have a place. I truly believe that they are an excellent way to show the unification of a series of stories that have a unifying theme. They also make great placeholders for those things that we know are very large, but aren’t going to necessarily address yet. Once we are getting to a point where we can see that the epic in question will need to be implemented, we can break it up. What I am suggesting is that we need to be careful about how and when we use them. We can’t allow them to distract from the discipline required in making our user stories small, independent and singular of purpose. I don’t believe that every story should start as an epic then be broken into its component parts. I especially wouldn’t want to see the epic become the primary planning instrument, thus becoming a fertile ground for creating waterfalls.