Should your acceptance criteria be specified as Given/When/Then or checklists?

This post is part of the Pride & Paradev series.

Should your acceptance criteria be specified as Given/When/Then or checklists?

You should specify your acceptance criteria as Given/When/Then

Given/When/Then is almost a ubiquitous way to specify user scenarios:

Given some precondition
When I do some action
Then I expect some result

If you write your acceptance criteria in this format, it not only provides a consistent structure, but if your automated acceptance tests are also specified in the Given/When/Then format then it makes translation from acceptance criteria to acceptance tests painless.

Your acceptance criteria are less likely to be nebulous as thought has gone into making them follow this consistent format with a precondition, action and expectation.

You should specify your acceptance criteria as checklists

Having acceptance criteria specified against a user story in checklist format makes the acceptance criteria clear and concise as there is nothing more than is needed. Given/When/Then scenarios can be verbose and hard to read on a user story card.

It also means these are easy to individually mark as complete by programmers as they implement the functionality (in a tool such as Trello).

But the biggest benefit is that acceptance criteria can’t be transferred directly from the user story to an automated acceptance test. This is important because acceptance test features shouldn’t replicate user stories: a user story is a change to a system, a feature is a collection of things that it does. So having a feature for every user story is a disaster, which is more likely to happen if your acceptance criteria are in the Given/When/Then format.

Having your acceptance criteria in checklist form also means there’s some human thought about how to implement an acceptance test for these. It might be that one acceptance test scenario covers three acceptance criteria checklist items, which is how it should be done, not simply a one to one mapping which can happen when using Given/When/Then format for both acceptance criteria and tests.

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

5 thoughts on “Should your acceptance criteria be specified as Given/When/Then or checklists?”

  1. Allison, I think we may need to clarify what acceptance criteria means here. It seems that you actually mean acceptance test scenarios here.
    If that is the case, I believe that the G/W/T style works well because of its consistence. Meanwhile, I agree that a user story can not be 1:1 mapped to an acceptance test scenario. A story itself is used to understand the feature with some real world context. There could be multiple scenarios derived from it.
    If we are talking about the broader concept of acceptance criteria, G/W/T may not be a one size fit all solution. For example, some acceptance criteria could be about performance, security, and other non functional ones, the checklist or a document may be good enough. G/W/T could not add extra values here.


  2. When going with checklist option (or a document), its effectiveness (or clarity) also depends on the author of the acceptance criteria. Same with some bug reports. I’ve seen some users just give a one liner title to the criteria (as checklist) w/ no clear & concise description of what exactly is to be verified for acceptance. They probably have it in their mind and assume others know or they were too lazy to document/write more details in the checklist item, but it matters from a tracking, archiving, and testing perspective. Lack of clarity can lead to miscommunication and possible wrongful acceptance (missed criteria or use cases).

    The G/W/T approach may not be ideal in some cases but at least it does force more documentation & clarification of the criteria to accept. I’ve never actually used G/W/T though.


  3. Love your Pride & Paradev series! We had tried to use “Given When Then” format for acceptance criteria on our stories, but found it was way too cumbersome. We’ve switched back to a checklist and find it is much quicker for testers/bas to add to stories, and easier for devs to read, too.


  4. It’s common to have multiple give-when-thens for a user story. The point is that by using natural language you can automatically convert these to code and start doing TDD/BDD. You could achieve the same with checklists by using data driven test automation. Horse for courses.


Comments are closed.