1

What is the difference between an Epic and a Sprint? I have a general idea of how an Epic is a collection of Stories which can sometimes have a collection of tasks. However, what I am confused on is: if an Epic is a collection of Stories, does that mean that a Sprint is a collection of Epics? Maybe it has to do with a Sprint's typical duration?

7

The concept of an Epic is related to that of User Stories, which come from Extreme Programming. There are two primary definitions for what an Epic is. In some cases, it refers to a very large User Story that needs to be broken down and decomposed into smaller User Stories that represent value-adding work that can be delivered. In other cases, it can be used to refer to a collection of related User Stories.

The Sprint is a concept from Scrum. It is a timebox that includes a Sprint Planning, a Sprint Review, a Sprint Retrospective, and Daily Scrum events along with effort spent to perform backlog refinement and to implement work. A timebox means that it has a beginning and a firm, fixed end point. Scrum defines a Sprint as a period of time that is no more than 1 month, after which the team produces a product increment that is suitable for delivery or release.

The Extreme Programming techniques are often paired with Scrum, which means that some teams using Scrum will express their Product Backlog using User Stories (and perhaps Epics). However, Scrum doesn't provide guidance on exactly how to represent Product Backlog Items.

  • I'd argue that using the word Epic to refer to a collection of related user stories is a problematic mis-application of the word that came about largely because of tools like Jira slapping "agile" words on existing features of their tool incorrectly. I raise this not to nit-pick, but because I've seen teams really struggle because of this misconception. – Daniel Jun 25 at 15:26
  • @Daniel I'd agree with this, but since both uses are pretty widespread (as far as I can tell), it's kind of hard to change momentum. – Thomas Owens Jun 25 at 15:27
  • Thank you very much. – Manseypants Jul 30 at 0:43
2

This is not an uncommon confusion, especially when you're looking at everything in terms of stories. It's much clearer if you start from first principles.

I'm going to give you an iteratively elaborate set of answers. :)

A Sprint is a timebox.

An Epic is a sizable work item.

...

A Sprint is a timebox during which a planned amount of work is done.

An Epic is a conceptually cohesive work item that is too large to fit into a sprint.

...

A Sprint is a timebox during which work is accomplished to meet the sprint goal. A set of stories that will meet the sprint goal and can be accomplished during the sprint timebox constitute the planned work for the sprint.

An Epic is a conceptually cohesive work item that can be divided up into smaller Stories, each of which delivers some business value and is small enough to fit into a sprint.

...

Example of a sprint goal: Add a gallery to the website. - This is a cohesive piece of work that may require working several stories (set up gallery of rotating pictures; select the pictures; add the pictures), but the work is small enough to fit into a single sprint.

Example of an epic: Add a store to the website. - This is conceptually a single "thing", but it includes infrastructure (secure credit card handling) and multiple features (search, filter, compare, shopping cart, user profile, order tracking, payment, etc): too much to fit into a sprint.

...

If you're looking at a pile of user requests, and you hit one that is either too big to fit into a sprint, or too big even to estimate, then it's an epic.

PS - If you're using JIRA as your ticketing system, you'll see JIRA helps you with this. You can create an Epic ticket type, but it will not show up in your product backlog. That's because an Epic is by definition too big to fit into a sprint, and the product backlog is by definition the place where you pull stories/tickets to populate a sprint. :) You have to create separate tickets (Stories, presumably) and associate them with the Epic; then those tickets will show up in your backlog, with a visual indicator of the epic that they're a part of.

(PPS - this is not a "pure scrum" answer. It's a pragmatic answer.)

1

An Epic is a large User Story which needs to be refined and broken down into small enough User Stories that can be delivered in only one Sprint.

An Epic is not a collection of User Stories, which suggests it is some sort of container.

At the inception of the product, a few generic directions for the product are drawn. It is already known that these are large chunks of work, thus some people call them Epics, but in Agile Project Management they are actually called Themes. The Themes are broken down into Epics.

But, at the same time it may happen that a Product Backlog Item that was considered initially a regular User Story is now called an Epic because during the refinement process the Scrum Team realizes it is a really big chunk of work, bigger than what they can deliver into a Sprint.

This kind of information emerges and this is a key difference between traditional project management and agile project management.

The Sprint is an iteration of the development process. It's a timebox, meaning it has a limited duration of time at the end of which the Scrum Team provides a working increment of the product. Because of this and in order to deliver each time a working increment ("new version"), the User Stories that are selected to be Done during the Sprint, must be small enough to fit.

The User Story must either be small enough, or be further refined.

The beauty of Agile and of the periodical refinement process is that much of the work that was planned to be done is not done in favor of the newer work that emerges constantly. That's why many Product Backlog Items are never done.

This goes against about the concept of having collections of collections of collections of work, which all need to be done at some point.

Lastly, the Sprint length is not determined based on the size of the User Stories. It is determined based on how often the product needs to be delivered in order to meet the business aspects and requirements (time to market, opportunities, risks etc).

So, we don't plan to deliver it all and compute how much it takes. This is traditional project management. We plan to deliver as much as we can (of what the customers actually need, while stripping down all what's not necessary) in the time we have. This is agile project management.

0

I want to provide a concise explanation of the two for you

Sprints

A sprint is a fixed time period where a team completes a set of issues that they've committed to.

Think of 1, 2 or 4 week Sprints where your team is fully focused on those tickets for the duration of the Sprint.

Epics

An epic is a body of work that can be broken down into specific tasks (called “stories,” or “user stories”) based on the needs/requests of customers or end users.

These specific tasks typically require no more effort to be completed, ideally, than can be accomplished during a single Sprint.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.