Acceptance Criteria vs. Definition of Done
Best to clear the air first in regards to a similar phrase some might conflate with acceptance criteria, and that is the “definition of done” or DoD. A DoD at the most basic level is a list of requirements that must be followed for a user story to be considered complete, or “done”. As test scenarios, acceptance criteria are specific and unique to respective user stories.
Simply stated, while both a DoD and acceptance criteria must both be met to consider a user story complete, DoD is common for ALL user stories where acceptance criteria is applicable to a specific one.
Effective Acceptance Criteria
There are a handful of elements that help determine just what makes effective acceptance criteria;
- Are they written from the perspective from the end-user
- Can they be tested properly
- Are they both clear and concise
- They must be easy to understand
The development of acceptance criteria must occur before before actual development begins otherwise the organization risks a smooth process and muddied expectations. In fact, proper consideration in the development of one’s acceptance criteria will help ensure that the scope is properly defined, it’ll help manage expectations and reduce confusion or ambiguity, establish criteria for testing for quality assurance, and in the end protect against mission/scope creep during the PI.
Typically there are two common formats for acceptance criteria to be written in; Given/When/Then, and Verification List. In the first format, which is quite similar to constructing user stories, begins with first explaining the scenario or framework. Then, given the specific context of the scenario, when a defined action is taken, then an explanation is provided as to the outcome of taking that action.
The Verification List style is much simpler and straightforward where a list of pass/fail statements is created and then referenced against.
Who Should Write Acceptance Criteria
Not surprisingly, as Agile methodology environments espouse collaboration, the development of acceptance criteria falls to more than just one individual.
Most often the responsibility is shared between the product owner, the development team, and the agile coach or Scrum master. And while the process may begin with the product owner, the final result must integrate the perspectives of all stakeholders involved and it must be a collective effort of the above-mentioned individuals.
The following is an example of a Feature with acceptance criteria as discussed in the SAFe article, “Features and Capabilities”.
Be A Team Player With Clear, Concise Acceptance Criteria
Are you part of an Agile team that has, or is looking to, transition to SAFe® and are looking for the right tools and advice on how to do so effectively? Reach out to us at Agile Hive and we’ll be happy to partner with you on that journey.
To learn more about how Agile Hive can be that resource throughout your entire SAFe® journey as your “SAFe in Jira” solution, reach out to us to learn more and when you’re ready, schedule a demo with us!
