Definition of Done & Acceptance Criteria or Conditions of Satisfaction

First let’s list all the terminologies, and the abbreviations I’ll use in this blog post:

  • Definition of Done (DoD)
  • Acceptance Criteria (AC), also called Confirmation, or Conditions of Satisfaction (CoS)
  • (Here lets’ say AC = Confirmation = CoS, there may or may not be any differences)

A bit more on AC, Confirmation and CoS:

  • Confirmation exists in User Story practice, User Story has 3 Cs including Card, Conversation and Confirmation
  • Acceptance Criteria is a synonym of Confirmation for User Story, and normally it’s converted into Acceptance Tests
  • Conditions of Satisfaction as Mike Cohn wrote, it could be regarding different levels than only User Story, but if we talk about Conditions of Satisfactions of User Story (CoSoUS…) let’s say it’s the same as Acceptance Criteria or Confirmation

DoD and AC are different things, in my opinion they’re actually in two orthogonal dimensions. I understood it in this way:

  • AC restricts the functionality part of an User Story, or say its external quality which users can experience
  • DoD restricts the quality part of an User Story, mainly internal quality and process quality

There are already some blog posts on their comparison, by using examples of real software features. I’ll rather trying to use an example from life. Consider you’re a football (=soccer) player or fan, you periodically train yourself in order to have better performance in some informal or formal matches. You might wrote several User Stories for your training schedule:

  1. As a Center Back, I want to practice long pass, so that I could initiate an attack from our backfield.
  2. As a Midfielder, I want to practice short pass, so that I could push forward via continuous short pass with other team members.
  3. As a Midfielder, I want to practice free kick, so that I could shot or pass better in a free kick opportunity.
  4. As a Midfielder, I want to practice Ruleta marsellesa, so that I could use it to dribble past opponent defenders.

For example, AC for the 1st user story of Long Pass might be:

  • Finish 10-rounds 50-meter long pass using right foot
  • Targeting the left-wing middle line, 8-rounds long pass
  • Left foot, aim to opponent’s penalty area, low pass

The DoD for it would be:

  • All hits should be cluttered within less than 2-meter-diameter circle
  • All practice plans should be recorded and checked by an coach
  • All practices should be videotaped and archived for further analysis

If you don’t satisfy the AC, user or customer will not accept the deliverables, coz the expected functionalities are not there. While at this time, the quality of finished functionalities might be world-class. If you don’t fulfill the DoD, you might still deliver your functionalities if they’re _usable_, they may even have very good user experience, but the way you build it may not be qualified or sustainable, nor its internal code quality satisfying.

  1. You might finished all training practices and they’re high quality, but not recorded nor videotaped, which could provide inputs to further training plan.
  2. You might finished part of some training practices strictly follow the DoD, but you’re still failed to execute the training plan given by coach.
  3. You might finished 10-rounds of long pass, but some are 60m-far, some are just ~40m, the performance is unstable, and coach is not satisfied, nor yourself.

My comparison as below:


Some might argue if they have listed all entries from AC and DoD here, and just call them DoD, what’s the matter? Well, from the delivery point of view, if you satisfies all the entries in AC and DoD (yes I knew it, you call AC+DoD as “DoD”), then this “Potential Releasable Product Increment” could be released by Product Owner, and it doesn’t make a big sense if we say it passed all AC and DoD, or it passed all “DoD” for that increment. I argued this with one colleague, a healthy argument, we’re not aiming to convince each other, but to understand the concrete reasons why separate AC and DoD matters so much (consider all entries are covered, just call them differently, one “DoD” instead of AC & DoD). We discussed and I shared my opinion, if I retrospect on it afterwards, my reasons are more like:  they’re two orthogonal dimensions, should be logically distinguished from each other, therefore it also make sense to distinguish them during its utilization. More or less because people learn from their practical experience, before they know or understand “DoD” or AC & DoD, and the reality they saw is “DoD”, they may not think if it’s actually two things and orthogonal, coz it’s working well. They’ll (or might) have problem while applying the practice to other organizations, because you need to explain it and adjust it to fit for the different organization. However this might be just my insistence, if they are different concepts logically, then I should separate them physically, this is my way, and I found it’s working well.

At the end, there are many people who supports various levels of DoD, e.g. US DoD, Sprint DoD, Release DoD, and so on. For me, it’s non-sense. DoD is regarding the way you finish a functionality. A Sprint is a timebox, even if there is a “Sprint DoD”, it could be simply as “When the Sprint timebox expires or abnormally terminated, it’s DONE.” Same rules apply for Release. They may argue that by “Sprint DoD”, they mean the DoD for Sprint contents. This is even more ridiculous in my opinion, any contents within a Sprint could be User Story or other stuffs, and the DoD works fine with it. Maybe they’re talking about the “Sprint content selecting process” DoD, but then it’s more a management activity, instead of development activity, and it’s quite simply, already defined in the Sprint Planning Meeting description.

To sum up, I would say:

  • Each User Story has several Acceptance Criteria (or called Confirmation, or Conditions of Satisfaction), and could be converted to Acceptance Test
  • Team should agree on DoD contents together with Product Owner, for all the user stories they’ll develop
    • consider a big product, has more than one team for a single product owner, I’d prefer all teams and PO together agree on one same DoD
  • At the end of Sprint, only the User Stories which satisfies AC _AND_ fulfills the DoD will be considered as DONE, and its Story Point estimation will be added up to their velocity formula.

Further readings:


Xu Yi is a professional Agile & Lean Coach, check out more at

Posted in Agile, Englist Post, Scrum, Thoughts
2 comments on “Definition of Done & Acceptance Criteria or Conditions of Satisfaction
  1. Kaveryjody this is is really useful, helped me out a lot thanks!

  2. du weizhong says:

    I like it.

1 Pings/Trackbacks for "Definition of Done & Acceptance Criteria or Conditions of Satisfaction"
  1. […] Definition of Done & Acceptance Criteria or Conditions of Satisfaction #DoD #AC #CoS #Agile […]

Leave a Reply

Monthly Archives