Scrum Epic: Definition & Examples

Instructor: Stephen Meyer

Stephen has worked as a Project Manager and is PMP certified, as well as certified by the Scrum Alliance.

Project work in Scrum is only taken on if it is in the form of a user story. Despite this, work items can take other forms, such as epics, that must be turned into user stories. Learn the definition and understand examples of Scrum epics.

Epics Defined

Lukas is a restaurant owner who has recently hired a software company to build a website for his restaurant. The software company uses Scrum and, in our scenario, assigns him the role of Product Owner. This is an important role, particularly regarding project requirements. Lukas thinks he understands user stories and writes some for the team. However, the response he receives is that he has actually written epics, not user stories. He is unfamiliar with this term and looks to understand the difference and how he can provide what is needed for the team to start working.

In Scrum, project work is broken down into smaller portions, known as user stories. These provide high-level details around desired functionality for a specific user and are written by the Product Owner who is responsible for the project and represents the key stakeholder. They are completed in repeated cycles, known as sprints. Quality user stories meet the criteria from the INVEST acronym, originated by Bill Wake, by being:

  • Independent (from other user stories)
  • Negotiable (flexible and able to be adjusted if needed)
  • Valuable (meeting a need)
  • Estimable (in terms of time/complexity)
  • Small (to be completed within a sprint)
  • Testable (can be verified by meeting criteria)

When a Product Owner writes user stories, they are evaluated against these criteria. If they meet each, they are confirmed as user stories. If they do not meet the criteria, they are not considered user stories. In particular, if they do not meet the estimable and/or small criteria, they are considered epics. Epics are user stories that are too large or too complex and need to be broken down further. This is the issue for Lukas and what he has provided as user stories. However, as he looks to make adjustments, he needs the team to help him better understand why user stories are identified as epics and to look at an example.

Identifying Epics

Once Lukas has an idea of what an epic means, he discusses with the team how they identify whether a work item is an epic or a user story. If he can understand these factors, he can provide them user stories rather than epics in the future. The factors involved with identifying epics are size, complexity, and the team's estimation ability.

One of the main factors in identifying epics is the size of a work item. User stories should be small enough to be completed within a sprint. Completion involves development and testing. If the combination of these takes longer than the length of a sprint to complete, the work items is not a user story, but an epic. In some instances, a work item could be completed within a sprint but would take the majority of the sprint. The development team could decide to identify it as an epic

Another factor in identifying epics is complexity. When the development team reviews user stories, they assign it a story point estimate, which is a value that represents the length of time and effort needed to complete it. If the team cannot assign an estimate to a work item because it is too complex, it is an epic, not a user story. Also, user stories should be in the most straightforward form possible. If they can be broken down further into more specific aspects of functionality, or more user stories, they are epics.

The last factor for identifying epics is the team's estimation ability. This factor is more subjective than the others because it is based on the team. The team should complete the user stories it takes on within a sprint. If the team does not complete user stories during a sprint and they are consistently a story point level or higher, the team might consider that level and above as epics. For example, if a team were consistently unable to complete user stories estimated at an 8 or higher, they would deem user stories estimated as 8 or higher as epics.

To unlock this lesson you must be a Study.com Member.
Create your account

Register to view this lesson

Are you a student or a teacher?

Unlock Your Education

See for yourself why 30 million people use Study.com

Become a Study.com member and start learning now.
Become a Member  Back
What teachers are saying about Study.com
Try it risk-free for 30 days

Earning College Credit

Did you know… We have over 200 college courses that prepare you to earn credit by exam that is accepted by over 1,500 colleges and universities. You can test out of the first two years of college and save thousands off your degree. Anyone can earn credit-by-exam regardless of age or education level.

To learn more, visit our Earning Credit Page

Transferring credit to the school of your choice

Not sure what college you want to attend yet? Study.com has thousands of articles about every imaginable degree, area of study and career path that can help you find the school that's right for you.

Create an account to start this course today
Try it risk-free for 30 days!
Create an account
Support