Acceptance Criteria & Definition of done

Last post 03:52 pm December 17, 2019
by Daniel Wilhite
20 replies
04:00 am June 17, 2018

Hello everyone, 


I have a question about the DOD and the AC please ! 


1 - DOD : did i need a DOD for every Epic / Feature / User story and Task of my backlog ? 

2 - same think with the Acceptance criteria, did i need one for every User story or Tasks of my backlog ? 


if  the respond is yes, so who is the memeber responsible for it in a scrum team ? 


thank you in advance :) 

04:28 pm June 18, 2018

What does the Scrum Guide say about this?

10:18 pm June 18, 2018

The short answer is that the Definition of "Done" applies to the entire product Increment, and does not apply to a Product Backlog item (or Epic/Feature/Story).  There is a myth that the Definition of "Done" is applied to multiple levels.  Just the Increment.

You won't find anything about Acceptance Criteria in the Scrum Guide.  What often confuses people is this statement: Product Backlog items often include test descriptions that will prove its completeness when "Done".

Acceptance criteria, which is optional and a complimentary Scrum practice taken from XP, may apply to the Product Backlog items, and is in the context to the desired functionality of the Product Backlog items.

Here is an example of each:

  • Definition of "Done": No Critical and High defect will be accepted; code coverage percentage to be at least 70%; all web pages to load in under 2 seconds
  • Acceptance Criteria: The password must be no less than 8 and no greater than 12 characters, contain at least one Uppercase letter, one lower case letter, and at least one number.

Think Definition of "Done" at the macro level, and Acceptance Criteria at the micro.

08:39 am June 19, 2018

A nice example I heard yesterday from Andy Brandt is:

You buy a car:

DoD: car passes the official technical checks and tests and is qualified to hit the road.

Acceptance Criteria: the trunk size is above X liters, it can do at least Y MPG, has built-in Bluetooth headset and is red.

10:25 am July 6, 2018

thank you so much everyone for the replay, now it's more clear for my little brain :)

07:21 pm February 20, 2019


Very interesting post. 

So, considering that the guide dosn't speak about acceptance criteria, is correct to say that the PO must not define and specify the acceptance criteria?

Thanks a lot. 


07:42 pm February 20, 2019

... PO must not define and specify the acceptance criteria?

Since it is the PO's responsibility to ensure that everyone fully understands the story why would defining the way that you know the story has been satisfied be a problem? I feel that the PO should provide acceptance criteria as part of the story definition. 

From the Scrum Guide (emphasis added by me)

Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done".

The last part about "often includes" is the key.  It is not an expectation in Scrum but it is a suggestion that there be some way of proving completeness.  From my perspective that is what the Acceptance Criteria provides. 

If you do a web search for user stories in XP (since that is where it originated) you find many references to the fact that the story must include one or more acceptance tests.  This comes from everyone's favorite site Wikipedia

Every user story must at some point have one or more acceptance tests attached, allowing the developer to test when the user story is done and also allowing the customer to validate it. Without a precise formulation of the requirements, prolonged nonconstructive arguments may arise when the product is to be delivered.

Since the developer is the one testing and the customer is validating, it seems logical to me that the PO should provide it since they are conveying the customer's wants/needs to the developers.

07:54 pm February 20, 2019

So, considering that the guide dosn't speak about acceptance criteria, is correct to say that the PO must not define and specify the acceptance criteria?

If a Product Owner defined acceptance criteria, do you think it would actually contradict the Scrum Guide and make an implementation of the Scrum Framework invalid? If so, why?

08:18 pm February 20, 2019


Thanks a lot. 

I agree with you, i express not very well my opinion in the previous question.

I would like to say, and i think is also the sense of your response, that is a good idea to create/define acceptance criteria but it is not mandatory.

Thanks a lot.


08:40 pm February 20, 2019


Creating acceptance criteria the framework is not invalid. 

I would like to say that it isn't obligatory, is correct? Do you agree with me?



09:02 pm February 20, 2019

Maybe I should have said: PO could not create acceptance criteria

In this way, considering the guide and your previous answer, is correct?


03:35 pm February 21, 2019

Hi , 

Very nice Post !! Thanks for the above answers. 

I have a further question on - 

"The short answer is that the Definition of "Done" applies to the entire product Increment, and does not apply to a Product Backlog item (or Epic/Feature/Story).  There is a myth that the Definition of "Done" is applied to multiple levels.  Just the Increment."

Is there a problem if we apply the same DOD for each PBI taken in our sprint ?

DOD for our PBI is - Each PBI must pass the code reviews, quality test, and integration test (if involves).

This ensures us the done and undone part of the PBIs taken.


04:27 pm February 21, 2019

I see no problem with the statements you make but why can't that be applied at the increment level instead of the PBI level? "Done" at the PBI does not necessarily mean that the increment will be "Done".  PBI "Done" is interpreted by Acceptance Criteria in my opinion. 

12:47 pm April 23, 2019

Chris Belknap:

There is a myth that the Definition of "Done" is applied to multiple levels.  Just the Increment.

Scrum Guide:

When a Product Backlog item or an Increment is described as "Done", everyone must understand what "Done" means.


 If the definition of "Done" for an increment is part of the conventions,...

So, for me either the first statement is false, or the scrum guide is a myth. 


03:27 pm April 23, 2019

@Norbert I originally had the same thought based on that single statement.  However, if you continue to read that entire section all other references to the DoD are applied at the increment level.  That is why I have come to understand the DoD as applied at the increment level. I also use the section that describes the increment as part of my interpretation (emphasis added by me)

The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be "Done," which means it must be in useable condition and meet the Scrum Team’s definition of "Done". An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.

Since all PBIs included in the Sprint Backlog are considered part of the increment, applying the DoD to the increment in effect will ensure that all items are done also.  

This statement in the section that describes the Product Backlog also plays into my interpretation (again emphasis by me)

 Product Backlog items often include test descriptions that will prove its completeness when "Done".

User Stories have become an industry standard but when they were originally created in eXtreme Programming, they did not contain Acceptance Criteria.  Those were added later because there was not a clear way to understand when the story had been satisfied.  That statement above indicates to me that the Acceptance Criteria (or similar statements in what ever method you use to write your PBIs) would serve as the DoD for the individual items in the backlogs.

The Scrum Guide is an entire body of work.  While we often refer to single phrases in these forum posts, in reality you have to use the entire guide and tie all of the information together.  Anyone that has worked in the software industry for a long time remembers the old waterfall Project Requirements tomes of 100+ pages. And if you haven't been in the industry for long, I am sure that you have heard the horror stories about them. As with those where you had to use all of the information, the Scrum Guide needs to be used as a whole and not in parts that satisfy your current dilemma. 

As the Guide states (once more, emphasis by me)

Scrum is free and offered in this Guide. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

08:25 am May 1, 2019

Norbert, it's fine to be confused. Knowledge comes in different shapes and forms, including from clearing up confusions. Like many (most?) others, over the years, I've had lots (and lots!) of confusions, on various topics (and not just work related :) )


Perhaps my comment here (March 28th) helps shed some light?

11:27 am May 1, 2019

Please don't try to scrutinise the Scrum guide and analyse every sentence, interpret it literally and consider it canon. Scrum is not a religion. It is a framework that you apply wisely.

When the guide doesn't say you should do something, it doesn't mean that you should not do it. Tailor up where needed. Inspect your own process and adapt where needed. 

As mentioned before, the guide states that there should be a common understanding of what it means when a PBI or an increment is Done.

However, it never says there should be only one DoD that applies to both. My teams usually have two, one describing Done for a PBI and another for an increment.

The DoD for a PBI typically contains things like code conventions, test coverage, review requirements, functional documentation, architectural guidelines, etc.

The DoD for an increment typically contains things like release notes, user manuals, regression tests, deployed on environment X, etc.


05:14 pm June 11, 2019

Henri, I agree with your assessment. The PBIs will have their own definition of done--not necessarily the same across all PBIs--and the increment will have a definition of done.  I admit, I do catch myself looking at the Scrum Guide for literals and absolutes rather than having it help shape how my team's practice Scrum.

10:52 am June 12, 2019

I think we're overcomplicating things.

One of the ideas behind using the notions of "acceptance criteria" for stories (PBIs) and "definition of done" (increment) was precisely that: simplify, as in use different terms (AC, DoD) to avoid confusions. 

12:52 pm December 17, 2019

Hi, I am new here.

As far I can understand (and in small words):

- If the (development) organization doesn't have a DoD, then the Development Team of a Scrum Team has to create their own DoD.

- Acceptance Criteria can be part of the PBI (of course, only when necessary).



- DoD applies to all increments, but parts of the DoD don`t apply to all increments (like update the wiki, update some other document...) . Is this true?



03:52 pm December 17, 2019

The Definition of Done is a statement made by the Development Team to the organization to communicate the final state of all work undertaken to deliver an increment of potentially releasable product. 

That sentence took me 4 minutes to write. I stopped counting how many times I changed it and I'm still not sure I like it.  For me it is a very hard thing to define the Definition of Done in an single sentence.  But, hey, I tried. 

@Antonio Moreira, your statement is not entirely wrong in my opinion.  There may be cases where a specific "clause" of the Definition of Done does not apply. But if the majority of the work done by a team would be considered incomplete or "unDone" if that condition was not met, then it should be included in the Definition of Done.  I perceive it like a contract template where some portions may be marked as Not Applicable in some situations.