The following is a (slightly modified) excerpt from Beyond Requirements: Analysis with an Agile Mindset.
What Are Acceptance Criteria
Acceptance criteria are the conditions that a solution must satisfy to be accepted by a user, a customer, or, in the case of system-level functionality, the consuming system. They are also a set of statements, each with a clear pass/fail result, that specify both functional and nonfunctional requirements and are applicable at a variety of levels (feature and user stories).
Liz Keogh notes that acceptance criteria are useful for several things:
- Further defining the boundaries of a story
- Serving as the functional requirements for the story
- Serving as a set of rules that cover aspects of a system’s behavior, and from which examples can be derived
Acceptance criteria point to things that need to be in place in order for the product owner or stakeholders to accept that the user story meets their needs.
As with all good functional requirements, the acceptance criteria should focus on business intent rather than detailing a solution, leaving those specifics for refinement during or right before delivery. Since we’re not looking to declare a specific solution, acceptance criteria tend to be implementation agnostic— describing what the team wants to accomplish, not how they’re looking to accomplish it. Those types of details can be left to models and examples, or to be figured out during actual delivery.
This example contains a set of acceptance criteria from the Agile Alliance conference submission system, specifically the ability for a reviewer to provide a review of a session proposal.
As Reed the Reviewer I want to review a session So that I can provide feedback to a submitter.
Mind Map of Acceptance Criteria
The figure below is an example mind map of acceptance criteria for the user story listed above. Each leg of the mind map represents one of the variables to consider when identifying acceptance criteria for Add A Review. Those legs are then broken into the various examples that are relevant for that particular variable.
(Graphic by Jeff Rains)
Potential Acceptance Criteria
- Reviewers must provide a title and description for the review.
- Reviewers may indicate whether they think the session should be included in the program.
- Reviewers may provide details of any conflicts of interest they have in reviewing the session.
- Reviewers may provide comments for the review committee.
- Submitters of the reviewed session can see only the title and description of the review.
- Submitters may see only reviews of sessions that they have submitted.
- Reviewers may review only sessions submitted to tracks on which they are reviewers.
- Reviewers may not review any session on which they are presenters or co-presenters.
- Reviewers may provide only one review for a session.
- The title of the review must contain 95 characters or less.
When to Use Acceptance Criteria
Acceptance criteria are used most frequently to provide further detail about features and user stories. Many teams find it helpful to identify some acceptance criteria fairly early, to assess the scope included in the story before they size it. Teams may then add acceptance criteria as they discuss the project further, understand the story better, and get closer to delivering the solution.
Why Use Acceptance Criteria
Defining acceptance criteria is a good way to start adding more detail to the skeleton of a story, and that’s where I see most teams doing it. Acceptance criteria are helpful in describing the scope of a story even if (or perhaps especially when) you are using a model to further describe the story. The model may serve as a reference for multiple stories, so the acceptance criteria lend some perspective to specifically which aspects are being delivered with a given story.
How to Use Acceptance Criteria
- Meet with the stakeholder(s) who are interested in the particular user story, someone with a development perspective, and someone with a testing perspective near a whiteboard or flip chart paper. Many teams refer to this group as the three amigos.
- Discuss the user story to determine what the stakeholder hopes to accomplish.
- Start discussing various things that the team should verify in order to make sure that they deliver the user story correctly. Use a mind map to aid that conversation so the group can see what has been discussed and use that to inspire additional thoughts.
- Note the acceptance criteria from the mind map and discuss whether all of the acceptance criteria should apply to that user story, or whether the number of acceptance criteria indicates that the user story should be split.
- Note the related acceptance criteria in your backlog repository of choice.
Caveats and Considerations
Some teams like to preface everything with “Verify that . . .” to reinforce that in order to call a user story done they have to verify specific acceptance criteria, but that seems a bit repetitive and fairly clearly implied. Other teams like to state acceptance criteria in the first person, such as “I need to provide a title and description in order to submit a review.” A derivation of that is describing acceptance criteria in terms of the subject of the user story, for example, “Reed needs to provide a title and description in order to submit a review.” Either way probably works fine and becomes a matter of taste for the delivery team, but this is certainly something helpful for the team to discuss and agree on.
RuleSpeak, created by Ron Ross, is a “set of guidelines for expressing business rules in concise, business-friendly fashion”. Since many acceptance criteria are a set of rules that cover aspects of a system’s behavior, it may be helpful to apply the precise ideas behind RuleSpeak when describing acceptance criteria, especially if you are in an environment with people who get very specific about how things are written. My only caveat is that you don’t want to get so hung up on getting the wording right that you spend more time on the form and lose site of the function. Again, the key is capturing information in a way that the members of the delivery team understand. Some precision is good. Excruciatingly exact precision at the expense of timeliness is not always so helpful. If the team chooses to use RuleSpeak in their acceptance criteria, the presence of a rule in the criteria indicates that enforcement of that rule is included in the delivery of that particular user story.
As with all the techniques described here, use your common sense to pick the pattern that works best. Don’t try to force a particular piece of information into a structure that doesn’t fit.
Some acceptance criteria items can also be conveyed by a model (such as the information included, and which pieces of information are required), but you may want to be explicit about how much you actually deliver with a given user story.
Also, since acceptance criteria are good for indicating the boundaries of user stories, you will often find that a long list of acceptance criteria is a good indication that the user story needs to be split into smaller stories.
After Beyond Requirements was released, I came across another technique to discover Acceptance Criteria called Example Mapping. I described it a bit more in my post on Agile2015 Highlights.
Keogh, Liz. Acceptance Criteria vs. Scenarios.
Mamoli, Sandy. On Acceptance Criteria for User Stories.
Want to know more?
If you learn better with video rather than reading, you may want to check out Analysis Techniques for Product Owners Live Lessons, a set of video training sessions that show you how to apply analysis techniques to product ownership. Lesson 5.4 focuses on acceptance criteria.
Analysis Techniques for Product Owners is available on Safari – O’Reilly’s online learning platform. Sign up for a 10-day free trial to view the video lessons.