Understanding Epic Terminology in Scrum


Another major topic for discussion here is the Epic, which many think is just a “large story.” However, I like to define epic as an item that can’t be committed to by the team. This could be for a variety of reasons, most of which are captured in the acronym CURB:


The item might be too complex to be understood well enough to be committed to.


Perhaps nobody on the team knows enough about the story. The story maybe unknown which does not allow the story to be committed to by the team, hence, it is an epic


There are too many unknowns; it is too risky to commit to the story without further investigation or a mitigation strategy.


It could just be too big to do in one sprint, even though it is well understood.

In any case, an epic is an item that contains at least one story, even if the story is just an investigatory one. Usually, an epic contains analysis stories that produce other stories that also belong to the epic. In other words, an epic is a container of stories, and we tend to refer to any container of stories as an epic.

Since an epic becomes an epic if the team can’t commit to it, sometimes we are surprised when an item we thought was a story turns out to be an epic during planning; we only find out when the team declines to commit. This is not unusual, because we can’t know whether or not we can commit for sure until we know what “done” means for the item.

Most capabilities are epics rather than stories; the main counterexamples being bugs or trivial features. If we think of a use case as being a typical capability for our software, then it is an epic, with the individual scenarios of the use case being potential stories. Of course, some of them might actually be big enough to be epics of their own.

And that in a nutshell is my marketing planSome examples of epics are:

  • “We want the system to be able to manage the pilots’ schedules”;
  • “We’re going to need to train all our users on this new release”;
  • “As a <tourist>, I want to <fly to Catalina for the weekend>”; or
  • “I need you to translate the website to Spanish, because I’m planning to do a lot of marketing of Catalina Air in Mexico”.


Epics is a Scrum term we use in our Glossary of Scrum Terms. The word Epic was not in earlier definitions of Scrum before roughly 2005. Epic is now a generally used word in most industry accepted descriptions of Scrum however, in most cases the word is poorly understood / defined. Our use of the word Epic here is defined against a body or list of Scrum Glossary Terms (Lexicon) that has been well established in the Reference book Exploring Scrum: The Fundamentals. The use of CURB is new (2007) and was introduced to anchor the concept of Epic to be something that is too big to be committed to in a sprint. Prior to anchoring the term Epic with the notion CURB, it was loosely interpreted to mean something like Big Story or Odyssey which was not as useful for describing how to breakdown and manage complex backlogs.


An online Tool that supports Epics in the context defined here is Get To Done®. Get To Done has just release Epics as a new capability into their online scrum tool.