Acceptance Criteria & Definition of done

What does the Scrum Guide say about this?

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.

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.

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

Hi, 

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. 

Flavio. 

... 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.

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?

Hi, 

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.

Flavio 

Hi, 

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?

Thanks  

Flavio. 

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

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

Thanks.

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.

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. 

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. 

Cheers.

@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.

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?

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.

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.

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. 

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).

Questions:

- 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?

Regards,

Antonio

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. 

Per the 2020 version of the Scrum Guide:

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even resented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

There is no much information about the Acceptance criteria in the Scrum Guide. If we have DoD but do not have Acceptance criteria does it mean we are in Scrum?

If we have DoD but do not have Acceptance criteria does it mean we are in Scrum?

Think of acceptance criteria as representing a certain level of Done, e.g. "Story Done". There must be a comprehensive Definition of Done for the Increment which is to be released, which may encompass multiple Product Backlog items. The DoD for the Increment will address matters such as the integration of that increment and its documentation and testing, as well as checking that any lower levels of Done are satisfied.

Having levels of Done can be efficient, in so far as doing so can allow inspection and adaptation to occur as closely as possible to the time and place of work being carried out. The important thing is to maintain transparency over the meaning of Done -- regardless of how many levels there might be -- for the Increment to be released.

In an effort to simplify DoD, can i put it like this?

DoD is basically acceptance criteria.  DoD= Organization's acceptance criteria for its products (if any) + Scrum team's acceptance criteria for each PBIs.

Example for Organization's acceptance criteria for its products, say a website) could be compatibility in different browsers, no dead links etc.

So, once the developers develop a PBI and test it for that PBI's acceptance criteria, they will check the organization's acceptance criteria list. If it is applicable to the PBI, they will work on it.

And, When should the DoD be defined? The PBIs need to be in a 'ready' state to be included in the sprint backlog (Guide: Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.).

A “ready” backlog item needs to be clear, feasible and testable. So, the 'basic' DoD is created before the first sprint planning.  Basic DoD would mean the first part of the DoD sum above. And, DoD keeps evolving through out the sprint. 



Is it a better way of understanding DoD. Any thoughts?

I think of DoD being applied to the product Increment and all the PBIs in the Sprint which are incrementally being added to it, so it applies at the macro level. Acceptance criteria, sometimes called test criteria, is optional and unique to every PBI, so it lives at the micro-level.

DoD= Organization's acceptance criteria for its products 

Keep in mind that not all organizations specify what done means for their products, therefore the Scrum Team must define the Definition of Done for the product they are working on.

And, When should the DoD be defined? 

If the Scrum Team does not have any ready PBIs or a Definition of Done, they may also create these in Sprint Planning of their first Sprint.

And, DoD keeps evolving through out the sprint. 

The DoD could change in the Sprint if adaption is warranted, but that is not common. Typically it is inspected formally at the Sprint Retrospective and changed there.

I agree with Henri van der Horst. No need to overscrutinize the guide as some things are kept vague to enable slightly different implementations, it's a framework not a rule book. In the current teams I'm working with we have a DoD for each US and one of the items is 'Acceptance Criteria has been met'. We define the A/C within each ticket to ensure common understanding of the U/S and also define what level of testing is sufficient to consider that U/S ready for Production.

We also use a Sprint DoD and Release DoD, although not as religiously, as it serves more as guidance for teams that start and might not think about things like deployment plans, etc. until it's too late. Once the Teams mature, they seem to do these tasks without the need for a DoD at that level.

I came across this in the exam 3 days ago and i was confused, i need clarity on acceptance criteria.I got 83.5% and maybe it could be my next ticket to passing PSPO I

I've crossed this topic while I'm preparing the PMP exam. As I understand it:

Definition of Done (DoD) focuses on the criteria that each deliverable or increment has to meet before we can consider them ready to use. That is: we put focus on the deliverable.

In turn, Acceptance Criteria (AC) focuses on conditions that need to be met before we consider that a requirement has been fulfilled. That is, we put focus on the requirement or user story.

What do you think?

The most effective way to inspect and adapt is as closely as possible to the time and place of work being carried out. That applies to the assessment of Done work as surely as anything else.

If the understanding of "acceptance criteria" which you outline helps the Developers to assure Done in a timely and transparent way, then that's fine.

Question then regarding non-functional requirements (NFRs), like security requirements:  where are these located in scrum so they can be consistently validated by all scrum teams.

If I have certain NFRs that I want to apply to the entire organization, how would that be done?  Create an Enterprise Definition of Done?

Do those NFRs represent negotiable scope, or do they reflect quality concerns which the Developers will be accountable for assuring?

Ian - the NFRs represent non-negotiable scope, like security requirements from our technical standards.

The Developers are accountable for quality, so quality requirements ought to be captured in the Definition of Done for the Product. Those standards cannot be negotiated away on a Product Backlog by others.

The wider enterprise can insist on a minimum level of quality, for all products, which the Developers in Scrum Teams must observe as a minimum. If you wish, you can think of this as an enterprise-level Definition of Done. The challenge lies in finding a way for the enterprise to own and maintain it.

so who is responsible in creating the AC? Is this the PO or like the DoD the organisation / Scrum team or the developers who work on the sprint backlog items?

AC must be in place before Product Backlog items are considered to be brought into the Sprint planning?

I too failed with 83,x% and AC was captured in a number of questions and no direct mentioning of it in the scrum guide.

Thank you for concise answers :-)

AC was captured in a number of questions and no direct mentioning of it in the scrum guide.

That tells you they may or may not be used. If they are deemed necessary for work to be ready, their elicitation ought to be accommodated within Product Backlog refinement.

Thank you...backlog refinement happens on an ongoing basis and the AC can act as a possible attribute that can be included in refinement of the the Product backlog items. Correct?

Even though the PO manages (is accountable for) the Product backlog. As AC are on 'User Story' level it would mean the PO is responsible to capture them to ensure the PBI is ready for selection, if this attribute is to be used. Would you agree?

Or am I overthinking it?

A quick example of how the DoD can evolve over time. It also can illustrate why it is about the whole increment.

Let's say we have an idea about a video game to develop. In the early stages, we are unsure about our concept and want to try it out with some users first.

So, we decided to spend several Sprints prototyping the game and try it with a limited number of users to gain feedback and adapt based on that feedback 

At this moment our DoD is not very strict about the quality, something like this:

- For each new PBI, the code needs to be reviewed and the Unit Test must be written and passing

- For each new PBI, the functionality of the PBI will be tested manually based on the acceptance criteria provided by the PO

- The entire PBI will be tested manually in the exploratory test manner. No crashes or critical bugs can be present. 

After concluding that we have now a good idea for the game, we decided to put it to a larger market.

Now our DoD gets stronger in regard to quality. Something like this:

- For each new PBI, the code needs to be reviewed and the Unit Test must be written and passing

- For each new PBI, the functionality of the PBI will be tested manually based on the acceptance criteria provided by the PO

- For each PBI there are automated functional tests created

- The entire PBI is tested with the Functional automated tests and manually in an exploratory manner

- Only minor bugs are allowed

I do want to look at the DoD and the completeness of the work,  while Acceptance criteria is the correctness of the work. Dev team can confirm the work has been completed. But the correctness  lies with PO who may take feedback from the user.