EPIC Acceptance Criteria?

Last post 08:52 pm January 10, 2022
by J Broderick
10 replies
Author
Messages
05:49 pm August 20, 2020

I've worked in organizations that use Acceptance Criteria (AC) at both the story and epic level and others where they only have AC at the story level. Curious on what you use and your thoughts on one vs the other. Thanks for your thoughts. Go:)

05:56 pm August 20, 2020

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

08:32 pm August 20, 2020

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.

03:10 pm August 21, 2020

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. 

02:25 pm June 8, 2021

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.

06:53 pm June 8, 2021

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.

07:50 pm June 8, 2021

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.  

06:05 pm June 9, 2021

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?

03:50 pm June 10, 2021

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.

10:58 pm September 15, 2021

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.

 

 

 

 

 

 

 

03:15 pm January 10, 2022

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?