When I recently asked a room full of people “What is the difference between Acceptance Criteria and Conditions of Satisfaction?”, I expected definitions to be agreed pretty quickly. After all, this was the opening gambit to take us on to the deeper discussion of their respective values and best approaches for implementation.
Turns out, it’s not a simple question.
The room contained a mix of experienced practitioners and those less experienced, but the understanding of these two terms varied and each of the three groups found it difficult to find consensus. One group proposed that acceptance criteria were specific tests that the team ran to ensure that a work item did what it should, another thought they were requirements that fed into the story, whilst another thought they were rough ideas relating to the work item. Quite a few people had not heard the term Conditions of Satisfaction.
Although I’m not the oracle on the terms, these are my definitions:
Conditions of Satisfaction (aka CoS) will usually be given by the Product Owner when a work item is presented to the team, and help describe what the user wants. The high-level rules that apply.
Acceptance criteria, although based on the story and CoS, are usually generated by the team to describe factors that would cause a test to pass (BDD scenarios would be an example of these).
For the user story “As a reader of the blog, I want to be able to leave comments, so that I can join in the conversation about the topic“, examples could be:
Conditions of satisfaction:
- Author doesn’t need to approve comments
Acceptance criteria:
- Given that I am reading an individual blog post
- And I am logged in
- When I leave a comment
- Then it should be immediately visible against the blog post
Having done a bit more research, it appears the group’s lack of clarity is unsurprising: even the agile gurus out there aren’t clear.
Mike Cohn seems to be a main proponent of Conditions of Satisfaction. In his book, Agile Estimating and Planning
, he describes CoS as “additional objectives” and “high-level tests about each feature”. For a user story of “As a user, I want to be able to cancel a reservation” he suggests the following CoS:
-
- A user who cancels more than 24 hours in advance gets a complete refund
- A user who cancels less than 24 hours in advance is refunded all but a $25 cancellation fee
- A cancellation code is displayed on the site and is emailed to the user
However, when I spoke to Mike about this topic a couple of years ago, he said “we can use Conditions of Satisfaction and Acceptance Criteria interchangeably.” He went on to explain that he has experienced problems when using the term Acceptance Criteria because people often refer him to the testers, whereas “by calling them something different – something that makes the person hearing it stop and reflect for a second – I find we have a better conversation”. Although he didn’t disagree with my definitions, I also never got clarity from him of what he saw as the real differences.
So I’m going to stick with my definitions until someone persuades me otherwise. You are welcome to come along with me or choose alternative definitions. But whatever you do, don’t assume that everyone else on your team thinks like you because they probably have a completely idea of what the terms mean.
Photo credit: Davide Guglielmo
OUT NOW!
The Innovation Revelation: A story about how to satisfy customer needs.
A real-world guide to taking a customer-focused approach to creating products and services that people actually want and are happy to pay for.
My opinion says that Acceptance criteria and conditions of satisfaction both are same thing presented differently. This is just a matter of presentation how these are created and presented.
If at all someone wants to know the difference, Conditionof satisfaction is something that the product owner has described and based on that Acceptance criteria is created and used to validate if the conditions of satisfaction is fulfilled.
David, I think your definitions are correct. i.e. these are two different things and unfortunately people have conflated the two.
Acceptance Criteria are perfectly clear (to me) and don’t need further clarification.
Conditions of satisfaction, though, need clarification.
First, the name “condition of satisfaction” (like many other Agile terms) is poorly worded
It would be better to call them “Story conditions” or “Story constraints”.
Yes, there is some overlap in them but only because what you build and what you test have to be related. But they won’t overlap 100%
I define Conditions of Satisfaction as additional conditions or constraints that must be applied to the story during implementation.
e.g. if a story about withdrawing money from an ATM has a condition of satisfaction that only increments of $20 can be withdrawn, then yes, there will be an acceptance criteria tied to the $20 increments. But they would be articulated in much more detail. e.g.
1. Validate that the withdrawal amount must be equal to or less than the account balance
2. Validate that a withdrawal of a multiple of $20, between $20-$300 can be performed (because of a maximum of $300 per withdrawal is another condition of satisfaction)
3. Validate that $300 is not allowed
5. Validate that $20 multiples >$300 are not allowed
6. Validate that non-$20 multiples between $20-$300 are not allowed
7. Validate strange numeric amounts/combinations are not allowed (all zero’s, all 9’s, 20.001)
i.e. there are both positive and negative tests in the acceptance criteria, but these are not necessarily specified in the conditions of satisfaction.
The problem with the term “Acceptance Criteria” is that is makes people believe that a narrow “Acceptance Test” matching that criteria is all testing that is needed to be done. Or worse, it may lead teams to ignore fixing problems because they’re not needed for “acceptance”. That’s a recipe for lousy quality. In reality, an acceptance criteria is just a user_story/requirement detail.
There really is no need for Conditions of Satisfaction. Acceptance criteria isn’t just for test scenarios it articulates in simple language what is acceptable for the Product Owner who is representing the user’s experience. I mean, AC is literally written from the user perspective and is not complicated. CoS add no value whatsoever if you write your AC and your stories properly. If you need CoS as well then you’re not articulating the AC clearly.
Keep stories simple.
I have always known Acceptance Criteria as the things that need to be true when the story problem is resolved. Based on that AC and COS are the same. With the introduction of BDD into the mix, POs are being told they have to write tests. I do not agree with this. They need to communication the business problem with context and acceptance criteria so the team can determine a solution. The solution they create should have many BDD (and other) tests, that not only cover the AC but other scenarios. I have seen this manifest as 1. the PO is expected to write BDD tests for the team as AC or 2. PO do not provide any acceptance criteria leaving the team to guess what it looks like from a business perspective when the problem is solved. I agree with the sentiment above ” Keep it simple”. Stories provide Who , What and Why, AC lets us know when we have solved the problem from a business perspective. Tests are written and performed by the team when delivering a solution.