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