Acceptance Criteria: or How I Learned to Stop Worrying and Love Conditions of Satisfaction

"Of course, the whole point of a 
Doomsday Machine is lost, if you 
*keep* it a *secret*!"  
- Missing acceptance criteria?

A definition of done applies to all product backlog items, but sometimes you need to define a set of important requirements that are unique for individual stories before they are worked on.  These are considered “conditions of satisfaction” for the product owner, or acceptance criteria.

Example: As a player, I want to see a Message-of-the-Day (MOTD) from the developer so that I learn useful things about the game.

Some acceptance criteria for this story might be:

• The MOTD window may only take half the screen.
• It’s only shown the first time someone starts the game during a calendar day.

Keep in mind that acceptance criteria shouldn’t be a huge list of design specifications.  These are a limited set of specific “must do” criteria that the team needs to know up front.

Types of acceptance criteria:

• Specific functionality known up front (above).
• Special, non-functional requirements (e.g. memory or CPU performance limits), for example “The game should have ten of these effects running with less than 2 milliseconds per frame cost on the target platform”.
• A set of expected behaviors for a subset of features, such as needing persistence in saved games or needing specific tests for online gameplay.   
• Known areas that will be incomplete.  For example, if you’re implementing a jump feature, but don’t have enough animation support (and have failed to get more), an acceptance criteria might say “some animation transitions will pop”.

Good acceptance criteria will:

• Have a clean pass/fail, testable state.
• Won’t dictate implementation details.

Who and When?
Acceptance criteria can be added to a story any time before, and during, sprint planning.  Usually they’ll be added in release planning, grooming and sprint planning with greater detail added as the sprint work approaches.  The product owner doesn’t have to be the one to identify them all, but should be present when they are captured.  I prefer to have the team there as well asking questions and suggesting acceptance criteria along the way.  One useful approach is to have a member of QA or a developer capture any acceptance criteria during discussions of the story, especially in sprint planning.

The Point
Acceptance testing will focus the team on the outcome as much as the means of getting there.  It allows the business side to build trust with the team and to improve how they communicate their needs.  When trust exists, the business is less likely to worry about the sprint and interfere.