What Do You Look for When You're Reviewing Acceptance Criteria?

Questions
#1

Following on somewhat from Gems post Acceptance Criteria: who, why, how, etc

What do you look for when you’re reviewing acceptance criteria?

For me, one of the key things I look for is: does the team have a common understanding of what they mean? I think without that, most other things I’d look for fall by the wayside.

What about you? What’s important for you when reviewing acceptance criteria? :thinking:

1 Like
#2

Checking off my list

  1. Are they complete? Shouldn’t be any gaps
  2. Are they written in non-technical language so they can be understood by a non-technical person
  3. Do they fit in with ACs for other stories? They should make sense in the context of wider work being completed.
1 Like
#3

testability - how well can we test the AC? ie is the criteria worded in a way that makes it testable. Are they open or closed questions?

testability - primary method of testing: exploratory, automation (api, ui, unit)… I wrote about analyzing the AC/Requirements here:

1 Like
#4

One word - Examples. I need examples of how the feature works, especially for APIs. It helps to avoid ambiguity.

1 Like
#5

@heather_reid - I asked a related question for APIs.

#6

In the telecoms space, it is not uncommon to see something a little abstract, like:

  • No P1 defects
  • P2 defects to be fixed in x days
  • P3 and P4 (where P4 is usually cosmetic) defects fixed at next release.

Testing is often referenced back to requirements so known coverage at any given point is a function of tested and untested requirements.

1 Like
#7

Here some points that I reviewed:

  • Each product item or user story should have at least one acceptance criteria.
  • Each acceptance criteria is independently testable.
  • Acceptance criteria must have a clear pass/fail result.
  • Include functional vs non functional criteria
  • focuses on the end result
2 Likes