It should come as no surprise that the smaller the pieces your team can break their work into, the better chance they’ll have at succeeding at that work. After all,…
It should come as no surprise that the smaller the pieces your team can break their work into, the better chance they'll have at succeeding at that work. After all, smaller pieces not only reduce the risk associated with your work, but they can also be easier for your team to understand.
In fact, breaking work into small pieces is so beneficial for your team, that most agile methodologies is to do everything possible to encourage you to do so.
But, despite all of the obvious advantages of breaking work into small pieces, teams who are new to agile still find themselves hiding large pieces of work inside of epics.
To be fair, epics aren’t inherently evil. They can be a great tool for storing loosely defined work on the product backlog, or for grouping smaller and related pieces of work in a logical way. In fact, there are quite a few perfectly valid uses for epics.
What’s Wrong With Epics?
Unfortunately though, many teams tend to use epics as way to enable their bad habits. In particular, epics can encourage poor refinement of ideas by enabling people to capture details in epics that they would otherwise consider too poorly refined for a normal user story. This can result in poorly refined stories being hidden on the product backlog, under the guise of epics.
While at times this can be acceptable, the trouble arises when epics are slated for teams to work on during a sprint rather than slating the individual stories that comprise those epics. This is because while it can be perfectly acceptable to load the component user stories of an epic directly into a sprint, the epics themselves should never be loaded as a sprint level item.
Loading an epic directly into your sprint allows you to hide larger work inside of your sprint than would otherwise be acceptable. And, when work is not broken down appropriately before loading it important details become much more likely to fall through the cracks and missed by your team.
This can result in vague and poorly defined work which can be tough to prioritize.
So What Should You Do?
Remember that epics are just another type of user story. Don’t lower your bar of what’s considered acceptable for an epic just because it’s larger than a normal story. Instead, simply consider an epic to be a story that’s been refined to the point that’s most appropriate for where that story is at in its lifecycle at that time. This may not mean that an epic should adhere to the same Definition of Ready as a typical user story, but some level quality should still be applied to it.
However, if your team still seems to struggle with understanding what the appropriate level of refinement is for an epic, it may be time to eliminate them from your toolbox until your entire team has a better understanding of how to get the most from this particular tool. This doesn’t mean that epics will never be appropriate for your team, but until everyone has a better handle on how to use them appropriately it may be time to take them off the table.
Want to learn how to get even more out of user stories? Check out my course, Creating Effective User Stories, for easy techniques that will have you writing better user stories today.
Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.
No Comments on The Case for Eliminating Epics
