While it may seem odd to propose “acceptance criteria for acceptance criteria” as a way to specifically address the quality of AC requirements, that’s precisely what we’re doing here.
We believe a checklist of quantitative AC measures is necessary to measure the requirement’s quality over time; this goes well beyond the more vanilla approach we often hear. There’s less chance of misinterpretation of acceptance criteria, and by doing so, we prevent significant delays early in production.
Developing a checklist leaves a more explicit set of conditions for requirements. Empowered development teams reject stories at will when AC lack clarity. Assumptions about improving AC quality over the implementation lifecycle rarely bear out, leaving no trustworthy route toward enforceable high-quality requirements. But it is so important to have well-written requirements.
So let’s start there by developing a checklist for Acceptance Criteria.
A Checklist for Acceptance Criteria – AC for AC
1. Write AC That Is Understandable by All Stakeholders
A bias often exists toward writing overly technical acceptance criteria when writing user stories. AC that spends time defining technical requirements within the checklist of AC is inadvertently stating the desired solution instead of articulating the requirement’s intent.
While there is room for technical user stories in the backlog, often called Non-Functional Requirements, the bulk of the product backlog comprises Functional User Stories. Within these stories, anyone reading the acceptance criteria should be able to understand the intent of the requirement.
2. Write AC in First Person, Active Voice
Write acceptance criteria in the voice of the person who draws value from the story. Similarly, the writer’s language should reflect words the user would say. Widely accepted within Agile circles is the recommendation to write AC in the first person, using active voice.
For example, “I can search for a name” is an acceptance criterion that is clear, straightforward, and easily understandable by anyone reading it. It communicates the value the user gains from their unique perspective and uses language that the user would choose to share the value they derive.
Another technique to consider is developing a vernacular within your AC to know the general direction of the solution you intend – without stating the implementation. For example, the AC above “I can search for a name” indicates the existence of a search field, that perhaps there is an active click required, and that my action generates results.
In yet another instance, you might consider writing your AC by suggesting the intent driving the solution you’re looking for. “I can search for registered names” might imply that the search is validated. “I see names that I am likely to search for” might steer the developer toward implicit search or some caching of previous searches.
The art of writing in the user’s voice includes enough detail to influence the result while not specifying the solution in the AC itself.
3. Write Using Concise, Prosaic Sentences
Brevity is the key to writing well, especially when writing good AC. “Omit needless words… Make definite assertions,” as Strunk & White said in The Elements of Style. When AC begins to include technical or business jargon, they become unnecessarily long and complex. They also start to be fragile from a testing perspective. Many solutions may be successful when designing for user needs, but not all will pass long or technically complex acceptance criteria. The reason for driving toward short, prosaic sentences is that readers can easily converse about them.
Also, brevity and prose are not necessarily unambiguous. “Definite assertions” in this context does not mean “mathematically provable.” Judgment often resides in the eye of the user or product owner. Powerful AC comprise words that the user would speak. AC will always require disambiguation, but it is not the AC’s place to do that. Disambiguation should be taken care of in the specification of tests.
4. Make An Assertion
One of the most common errors in writing AC is to annotate the technology. There is a place for annotation, but AC is not it. AC should be an assertion. You can tell that you are wandering from opinions into annotations when you begin to see AC that sound like, “The search bar is in the header” or, “The button is light blue.” These annotations are fine and sometimes helpful when receiving wireframes or updated UX. However, these statements speak nothing of user value and should be avoided.
Another common mistake is writing acceptance criteria in terms of the actions that need to be completed to deliver the value. There seems to be a natural tendency for people to think about tasks vs. outcomes – e.g., “What do we need to do?” instead of “What value do we need to produce?” This mistake happens at the story definition level as well. Many will write about a specific action rather than writing a story title or description regarding value. Actions are necessary, but they are not AC.
5. Write AC with Focus on a System Output, a Resultant State, or a Response
Much good AC will start with phrases such as I can…; I see…; or I have…. Sometimes negative statements will also produce the proper response: I cannot…; I do not…. By beginning AC with these phrases, we constrain ourselves to the story’s intent.
Complex scenarios can exist, many of which are not easily distilled down to short, prosaic system outputs. In such situations, you can supplement AC with a truth table or annotated wireframe, but these addenda should not be considered replacements for clear, testable outputs.
6. Good AC Is Independent of Implementation
As in the test of communicating value in the voice of the one deriving it, the test of implementation independence will allow for developers to approach the conversation creatively. When AC becomes prescriptive, creativity and innovation are stifled.
Technology professionals with years of experience can share war stories of 300-page PRDs that became instantly obsolete with the first version update. AC should be evergreen in that the user will get the value they need, regardless of whether the implementation is changed or updated.
7. Stay in the Problem Space, not the Solution Space
Writing good acceptance criteria is about staying in the problem space and out of the solution space. In The Lean Product Playbook, Dan Olsen defines problem space as “a customer problem, need or benefit that the product should address.” In contrast, the solution space is “a specific implementation to address the customer need or requirement.”
Olsen offers additional insight in a Medium blog entitled A Playbook for Achieving Product-Market Fit:
“Problem space vs. solution space helps you to understand what is that true competition and substitutes for the need that you are addressing,” Olsen writes. “The classic example is that in the 1960s, NASA contractors spent millions to develop a space pen so that American astronauts could write in space, whereas the Soviet cosmonauts used a pencil.”
People live in the solution space without ever asking about the real problem. In the product world, many teams rush into the solution space by coding new features without getting a clear idea of the problem space in which they find themselves. A user story’s AC should stay in the problem space, focusing on why a customer wants or needs your product. The solution space can live in the story, not in the AC.
Focus on the Fundamentals!
To improve the success rate of software projects, focus on the fundamentals. One of those fundamentals is requirements definition. On Agile projects, acceptance criteria are a form of requirements definition. Does your team’s acceptance criteria follow the guidelines we wrote here? If not, we would encourage you to consider them. Focus as much attention on improving the quality of your acceptance criteria as you do on other quality improvement initiatives.
Editor’s note: This post was originally published in October 2019 and has been edited and updated for accuracy and comprehensiveness.
Get started with writing clear acceptance criteria.
Download a PDF version of our AC for AC Checklist.
Paul Gebel is the Director of Product Innovation at ITX Corp. He earned his BFA and MBA at Rochester Institute of Technology, where he currently serves as Adjunct Professor. A veteran of the United States Navy, Paul’s experience also includes extensive project and product management experience and consultancy. At ITX, he works closely with high-profile clients, leveraging technology to help solve business problems so they can move, touch, and inspire the world.
John Roets is a Principal Software Engineer at ITX Corp. He and the teams he works with follow Agile development practices. John has an MS degree in Software Development and Management from Rochester Institute of Technology and a BS degree in Electrical and Computer Engineering from Clarkson University. His interests lie at the intersection of technology, business strategy, and software processes.
