Epics aren’t very good for driving the development team because Epics lack sufficient detail and will take too long to complete anyway. But Epics are, like their smaller relatives the user story, great as a place holder for a conversation.

Why we should ban Epics

With immediate effect: Epics will not be allowed – just say No to Epics, stick with stories

Allan Kelly (@allankellynet, 4 Mar 2013)

Epics make pretty poor requirements. They are inevitably vague and that means the developers don’t know what they are meant to build and might just make it up. The vagueness also means there is also a good chance the team will get bogged down in unforeseen issues.

Epics are also pretty poor indictors of progress – critical for monitoring and control – because they are by definition too large and will take too long to develop. “I’m working on Epic-X”every day for 3 months doesn’t offer sufficient insight into what is happening.

The term Epic was coined to indicate that a user story was too large. And only small user stories should be pulled into the development process. Small brings greater clarity, less chance of unforeseen issues, and more transparency on progress.

Why I love Epics

My product backlog is entirely filled with Epics. As I described in my post on the Agile Requirements Snail I like to refine requirements over time. So from my perspective my product backlog is full of placeholders for a conversation. Actually several conversations answer several questions. What are the user stories? What is the relative priority of these user stories? Are the user stories the right size (a few days dev)? What are the test scenarios for each user story? etc.

I don’t want to have those conversations when the product owner first dreams up an Epic. That would soak up a lot of time and encourage waterfall like behaviour – trying to understand all the requirements before doing anything. So I am happy to have a vague requirement, actually lots of them, sitting in the backlog waiting.

But we do start the conversations on the top priority Epics. Product owner, business analyst, user experience designer, tech lead all help with requirements elicitation. They refine the top priority Epic(s) into user stories.

By the time the requirement moves into development the Epic has become a series of small user stories.

So by embracing Epics then rejecting them I can defer costly conversations but still ensure the development team gets what they need.