Reasons Why you Need a Good Acceptance Criteria

What is a User Acceptance Criteria?

User Acceptance Criteria or UAC, is the contract between the product owner and scrum team, letting them know what needs to be done functionality wise, in order to meet the user’s need and exit successfully. A set of explicit and exhaustive conditions, that detail comprehensively the scope of the user story, enabling engineers to understand what they are committing to when they accept a product backlog item into their sprint backlog.

By no means this is a simple exercise and sometimes involve sprint grooming sessions where the product owner and team collaborate to figure out what the minimum subset of functionality should be built.

How to Author User Acceptance Criteria?

There are certain rules that go into writing good UACs, foundational to delivering exactly what is being asked of:

  • Written from a customer’s perspective: Similar to user stories, you should articulate a requirement in the form of a customer journey.
  • Simple enough for anyone to understand: That is, not just your engineers or subject matter experts, but anyone picking up your user story, should be able to read and understand what the conditions for successfully completing it is. This includes being clear and concise, in one simple sentence.
  • Not an Engineering Task: The UAC simple resistances what the user wants, not how, and that is why it is bundled with a user story. The product owner sets what is needed, and the scrum team eventually responds with how, in the form of engineering tasks (or story sub-tasks).

A common approach to writing a user story is using the form Given/When/Then. As an example:

Given I select a profile avatar when scrolling a list of friends, then I should be able to see the user’s full profile. 

As you see, as a product owner, providing clear and concise and exhaustive list of user acceptance criteria as part of the user story, you give your sprint team every chance to assess exactly what work needs to be done, the effort, and thus no surprises during sprint review. Simple enough but something worth re-iterating over and over again.

Leave a Reply

Your email address will not be published. Required fields are marked *