Evaluating Acceptance Criteria
When is something “done” and when is it “right?”
Goldilocks and the Three Bears — a simple tale of a young girl visiting a family’s empty home, where she eats their food, sits in their chairs, and rests in their beds, evaluating them at each juncture — may be the earliest example of acceptance. For me, it is also a timeless lesson about the importance of clear and concise acceptance criteria.
Everything has acceptance criteria (whether stated explicitly or implied), which are defined by two boundaries: “done” and “right.” Goldilocks’s acceptance criteria are the implied kind — she ate porridge to relieve her hunger (done) and it met her temperature requirements (right). She sat by the fire to get warm (done) and the seat fit her body size (right). She stayed in bed to nap (done) and it was comfortable enough to sleep (right).
Agile product development and the emergence of user stories with explicit acceptance criteria shows that the team understands that “done” and “right” can be different for each reader. User stories are complete only when short, specific statements of acceptance are included. When we can picture both a “done” and “right” version of our user story’s product, then our acceptance criteria are explicit.
The Tree Swing — a classic project management teaching analogy — illustrates what happens when acceptance criteria is the implied kind. It demonstrates how we can reach vastly different results based not on what was said, but on the background and experience of each person’s point of view. Without explicit specifications, acceptance criteria are subject to interpretation, influenced by the bias of its reader.
A recent New York Times article on an artist pocketing money with blank canvases highlights how “done” and “right” are often open to interpretation. In the article, a commissioned artist felt it was valid — likely due to the absence of specifics — to re-imagine two of his previous pieces as blank canvases. The artist delivered the canvases (done) that fit the bill as “reimagined” pieces of work (right). If the commission had included acceptance criteria with specifications on the final pieces, however, the end result may have been different.
In conclusion, writing agile acceptance criteria is an exercise in explicit simplicity. To create clear and concise acceptance criteria, it’s important to think conversationally and put yourself in the shoes of someone with no prior context or knowledge, allowing them to develop a clear mental image of the difference between “done” and “right.”
Slalom is a global consulting firm focused on strategy, technology, and business transformation. Learn more and reach out today.
