EPIC Acceptance Criteria?

Does having acceptance criteria for an "epic" improve transparency over what it means for work to be "Done"?

What does an Epic mean for your organization?

Traditionally, an Epic is just a Story that hasn't yet been decomposed into smaller pieces of work that are deliverable within one iteration. In XP, where User Stories originated, a User Story that takes too long to implement and deliver would have to be broken down before work could start on it. In Scrum, you can see this in refined Product Backlog Items that fit into one Sprint.

However, some people use Epic to refer to a container of other work for tracking purposes. An Epic is complete when all of the work that is within it is complete. Today, this is often seen in how some tools (like Jira) treat issues called "Epics".

If and how you use Acceptance Criteria depends on what definition of Epic you use.

To add to what @Thomas Owens said about User Stories, in XP they did not initially contain acceptance criteria.  That was something added on later to help make sense of the stories. 

And it does depend on what an Epic means to your company.  I've seen Epics used for a new feature that are loosely defined like "Add the ability to export the general ledger to a format that can be used to create spreadsheets" but I have also seen Epics used for an initiative such as "Increase daily active user counts by 10% week over week".  The latter statement is clear enough as acceptance criteria where the former statement has ambiquity in what format is used. 

The situation varies by occurence and, as with all things agile, there isn't a hard rule on what is the right thing to do.  And I refuse to even mention best practices.  I really do no like that term.  There are no best practices, just a whole lot of good ideas worth considering. 

interesting topic... but it makes me feel that not including acceptance criteria at an epic level generates a whole and let me explain the why:

If we use epics as containers of future work with no acceptance criteria, then we are generating rework, because how can the team try to understand the complete backlog and build a primary version of a roadmap without considering how work can be completed and without considering the effort that can represent? also, we can potentially open a door for not identifying dependencies and/or input needed.

To close my point, we should consider building an Epic to include the acceptance criteria, having a backlog with "containers" does not generate trust.

Rework in Scrum is both necessary and expected when it results from empiricism and learning. Epics may not be well understood for example, and clarity will be emergent. It's ongoing delivery that generates trust, not detail in specification. Detailed specifications are resorted to, often precociously, when trust is absent. The detailing of acceptance criteria should perhaps be seen in that light.

If we use epics as containers of future work with no acceptance criteria, then we are generating rework, because how can the team try to understand the complete backlog and build a primary version of a roadmap without considering how work can be completed and without considering the effort that can represent? also, we can potentially open a door for not identifying dependencies and/or input needed.

To close my point, we should consider building an Epic to include the acceptance criteria, having a backlog with "containers" does not generate trust.

I agree that a Product Backlog full of containers is not useful.  But if you use Epics as containers, wouldn't the individual stories tied to that container be creating the Acceptance Criteria for the container?  The Product Backlog is defined as such in the Scrum Guide

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Based upon that statement, I do not see Epics-as-containers as part of the Product Backlog because they describe no work.  They are just a way to associate actual work together in a way that the organization/team can see relationships. 

If you are in fact creating Epics that have work described in them, acceptance criteria can be useful. But if that is the case I would argue that your Epics are actually user stories some of which might be too big for a single Sprint.  

So, once an Epic is decomposed into a one or more features, should we remove the Epic from the Product Backlog? The acceptance criteria will be in each of the underlying features?

Similarly, once a Feature is decomposed into one or more stories, should we remove the feature from the backlog? The acceptance criteria will then be in each of the stories?

When appropriate, should we remove all ‘containers’ from the Product Backlog?

Presumably, this also avoids the problem of duplicated or double (or triple) counting estimates at Epic, Feature and Story levels, respectively?

Containers can remain in the Product Backlog and can even be moved to Done when all of the work is completed for that container.  It all depends on why and how you are using your containers. The team working from that Product Backlog are the only individuals that can answer your last questions. 

The Scrum Guide states the responsibility for the Product Owner as such:

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is also accountable for effective Product Backlog management, which includes:

• Developing and explicitly communicating the Product Goal;

• Creating and clearly communicating Product Backlog items;

• Ordering Product Backlog items; and,

• Ensuring that the Product Backlog is transparent, visible and understood.

The Scrum Guide states this in the Scrum Master's responsibilities

The Scrum Master serves the Product Owner in several ways, including:

• Helping find techniques for effective Product Goal definition and Product Backlog management;

• Helping the Scrum Team understand the need for clear and concise Product Backlog items;

The Product Owner and Scrum Master should work together to find effective ways to manage the Product Backlog. The Product Owner could make these decisions but a good Product Owner will involve the rest of the Scrum Team in the discussions on how they feel is best to use the Product Backlog to the team's advantage.

My view is:

 - An Epic is a way to group User Stories

-If you group User Stories into Epics then the completion of the User Stories in the Epic means the Epic is complete. Each User Story has Acceptance Criteria ergo when the User Stories are 'Closed' the Epic is fulfilled.

- A User Story can be present itself that is actually an Epic that needs to be broken down.

- If you start using Epics, a burden emerges of having to group User Stories into Epics. 

- What value is there in Epics anyway?

I'd be interested to hear what the OP has to say about his experience with organisations that use acceptance criteria in Epics. To me it seems like a waste; the Acceptance Criteria is in the stories and the Epic is merely a categorisation.

Have a different perspective @Ruth Russell.



Epics (@Thomas Owens shared) are simply User Stories that are too big to be completed in 1 iteration (whatever that may be - as we are talking about Scrum - we'll use a sprint). As @Ian Mitchell said "Does having acceptance criteria for an "epic" improve transparency over what it means for work to be "Done"?" if so - great that is what I would hope they would be for.



If we look at what AC's actually are: Criteria which a customer (in the case of Scrum, PO) will evaluate the story for completeness to what the story should actually do (for the user) - this brings clarity to the story (Epic) or, as Ian said, improves transparency why not add AC's....OR...at Epic level would CoS suffice?

I am just setting up the Product Backlog for my new Project and am also confused whether Epics should have Acceptance criteria. As per my understanding Epics are larger User Stories which cannot be completed in 1 Sprint and need to be broken down.

Say we mention the Acceptance Criteria for an Epic and also for the User Stories when we break down the Epic. Are there not chances that the Acceptance Criteria for an Epic would differ from the User Stories because we may have more information while breaking down the User Stories.

Would we not be required to change the Acceptance Criteria for the Epic also?

I am thinking of having the Acceptance Criteria only at the User Story level.

You can think of acceptance criteria as representing a certain level of Done. There must be a Definition of Done that applies to the Increment, but that is not necessarily a monolithic commitment. Bear in mind that the best way to inspect and adapt in lean and agile practice is as closely as possible to the time and place of work being carried out.

Acceptance criteria are sometimes referred to as Story Done. You could reasonably have a further level of Done, such as acceptance criteria, at an epic level. Having multiple levels of Done can help to assure quality in a timely way, and can mitigate the risk of an undone Increment.

My opinion on this hasn't changed in the 1.5 years since the original post was made. However, I want to point out that this entire conversation really has nothing to do with Scrum since User Stories and Epics are not mentioned anywhere in the Scrum Guide.  User Stories are a practice originating in eXtreme Programming (XP) that have been adapted and adopted by many organizations.  The "right way" is something that each organization decides for themselves. 

Thanks for the clarifications.

I agree that epics become just a container of stories when decomposed. I always say the acceptance criteria for the epic is the stories. I think there is great benefit is structuring your product definition with epics to communicate when a set of functionality that the business expects is complete. 

And yes yes yes epics are emergent. This is part of how we define the product. If you create an epic and list some acceptance criteria as a starting point, that acceptance criteria is often the stories you need to create for the epic deconstruction. Ideas arise through the deconstruction and ultimately the epic emerges as the functionality of a product delivered.