Scrum for Team System Guidance / Version 3 / Epic

Epic

There is a lot of confusion about Epics in Scrum, and there really doesn't have to be.

The term is also linked very much so to User Stories, and that makes sense because in the traditional use of the word Epic means a "Very Large Story".

But this is where the metaphor breaks down, Epic stories are long and rich in detail and actually meant to be told, whilst Epic PBI's are never meant to be built and lack detail of any kind.

If your Epics contain loads of detail and information - like an Epic Story or poem, then you don't have an Epic in the Agile sense of the word you most likely have a specification.

But in Scrum it's best to think of Epics in this simple way:

"An Epic is any Product Backlog Item that is too large to completed in a single sprint"

 

---

When putting User Stories onto a Product Backlog (or feature list), you shouldn't feel compelled to break everything down until the features are nearing development.

Further down the Product Backlog, it's fine for items to be fairly fuzzy. It's also fine for items further down the backlog to bewhole projects - large, high-level items that are not so much User Stories but more like Epics!

As an item nears development, the item should be broken down further. And as it nears development, the item on the backlog should be defined in sufficient detail that the team can reasonably estimate its size and break it into tasks.

Until that time, however, it's just really a placeholder. A reminder for prioritisation and high-level estimating. That's all.

For some people, particularly those used to a more traditional project approach, used to detailed specifications up-front, this can potentially feel very uncomfortable. It shouldn't.

The logic here is simple. There is little point defining a feature (or set of features) in detail if it may never reach the top of the priorities. The other aspect of this logic is that you tend to know more about your requirements, constraints, etc as time goes by.

And things change. People come and go. Sometimes the team has changed significantly since the original requirements emerged, so information can be lost if it is captured too early.

Therefore it makes business sense to defer details until they are needed.