The heart of a user story
is its acceptance criteria. Also called conditions of acceptance, they constitute a set of conditions that must be met for the product owner
to accept delivery. That is the contract with the product owner for the user story. Acceptance criteria do not take the form of a formal document but rather are a few simple sentences that describe when the user story is done. Accordingly, they state the user story’s Definition of Done
The acceptance criteria make up the user story’s technical requirements, describing the expected functionality. They are the “what” of the user story; the “how” is determined by the Scrum team. Because acceptance criteria form the basis upon which we build and test the user story, they must be properly written.
Think of this like buying a car. When you look at cars, you have a list of must-haves and nice-to-haves. The must-haves are the acceptance criteria, for you as a shopper and also for a user story. A demo, then, is like a test drive.
Whether we’re working on a defect resolution or an enhancement user story, we start with the demo. The Scrum team meets with the product owner to understand the requirements and begin to flesh them out. For this the team also enlists the help of a few developers and a business analyst at the demo. The goal is to determine how the team will meet the Definition of Done. Sometimes the demo determines that there isn’t an issue; sometimes the team finds a different solution; and most of the time everyone moves forward with the user story.
Let’s say the user story is a website enhancement that will add a new graphic and text to a website’s log-in page. Members of the Scrum team meet with the PO to discuss the user story and demo the website. This is an exploratory demonstration, so we can review the log-in page and discuss the new graphic and text. As we demo, we ask clarifying questions: Does the new graphic replace an existing graphic? Is the new graphic linked to another page? What is the new text? This is where we gather acceptance criteria and determine scope.
In this demo we find that the existing image linked to a page that will be retired. The page that the PO wants the new graphic to point to, however, is not ready. So the team proposes that the PO accept delivery of the new graphic without a hyperlink. The PO agrees to write a new user story to add a link to the graphic later. The new user story will go into the product backlog for prioritization.
This discussion with our PO gives us a mutually agreed-upon understanding of scope. It also helps us think about the conditions for acceptance or acceptance criteria.
The scope and acceptance criteria for this user story are:
- Replace an existing graphic with a new graphic, to be supplied by the PO.
- Do not hyperlink the new graphic to a different page.
- Replace the existing text with new text, to be supplied by the PO.
I have been in meetings where the Scrum team comes prepared with acceptance criteria added to the user story before it has been demoed with the PO. I am reluctant to do that; the acceptance criteria are the PO’s vision for the user story and therefore are the PO’s responsibility.
Again, think of this like buying a car. Who’s driving? When you’re on the lot, does the dealer tell you what a car should be in order to meet your needs, or do you tell the dealer? You tell the dealer, and the dealer helps you find what you want. In this example, you are the product owner, buying the car, and the team is the dealer.
Putting the PO in the driver’s seat has advantages.
- It puts the Scrum team in a position to discuss and define ambiguities.
- The existing graphic is linked to another website -- does the new graphic also link?
- If so, what is the URL?
- Is the graphic in the right format? Is it the right size?
- What is the new text?
- It keeps the team from overthinking the enhancement (which I call “creative scope creep”).
- In this example, creative scope creep occurs when a team member suggests, “Since the website for the new graphic isn’t ready yet, we thought we could link to a graphic of a dancing moose holding a banner that says, ‘Someday soon this will be a really cool page!’” However, the PO simply wanted the team to remove the link. We don’t want to build a monster truck when the PO wants a Jeep.
- It is not the team’s but rather the PO’s responsibility to define the scope of the user story. It is the PO’s contract with the team and the team’s contract with the PO.
- If a PO is reluctant or refuses delivery, the ScrumMaster can point out that it was built to the PO’s specifications and begin negotiating a follow-up user story.
Asking for acceptance criteria is an opportunity to reinforce Agile simplicity.
When asking a PO for acceptance criteria, I start with a clarifying statement, then a story to help the PO understand its purpose, then its stated purpose. My clarifying statement sets the expectations of acceptance criteria: “These acceptance criteria, also called conditions of acceptance, must be met for you to accept delivery. We will do more than this, but this is the minimum we must produce for you to sign off.”
Then I make it “real world” by telling a story about something that we can relate to. For now, I’ll stick to the car-buying story.
“Product owner, think of this like buying a car. When you walk into the lot, you know there are certain things that you must have, like automatic transmission or leather seats. And there are certain things you would like to have, like a sun roof or four doors. We’re looking for the must-haves.”
Then I go back to the business statement with a phrase like, “So let’s get back to acceptance criteria. What are the must-haves for you to accept delivery of this code? In other words, when we ask for sign-off, how will you test this?”
Either the PO will jump in and say, for example, “Well, when I go to the log-in page, I’ll see the new graphic,” or there will be silence.
If there’s silence, wait for it. . . .
Let it feel a bit uncomfortable for a few seconds. Try to let the PO speak first. Make him or her take responsibility for the acceptance criteria. Maybe the PO needs a few seconds to think about it, or needs help getting started.
Don’t leave your PO stranded, however. I don’t think it is the Scrum team’s responsibility to write the acceptance criteria, but I do think it is the team’s responsibility to help
the PO write short, detailed, mutually agreed-upon criteria.
After the silence, you might prompt the PO by asking, “OK, so, for example, when you go to the log-in page, do you see a new graphic?” or “When we did the demo, we said we would replace the existing graphic with a new one. How would you test that?” The PO might say, “Well, when I go to the log-in page, I expect to see the new graphic.” Hence the first acceptance criteria is, “When I go to the log-in page, I see the new graphic.”
Now the PO is engaged.
This should help get him or her thinking. As the PO comes up with acceptance criteria, help make it as clear as possible -- no ambiguity. In this case, the other acceptance criteria for the graphic is, “The new graphic is not hyperlinked to a different page.” If the PO doesn’t mention that the graphic is not linked, the team can guide the PO by suggesting, “Since the graphic is not linked, will you click the graphic to ensure that it is not linked?”
The final acceptance criteria is, “Replace the existing text with new text, to be supplied by the PO.”
The final product
During the sprint review, your team will demo the user story and compare the functionality it describes to the new functionality. During the demo you can reinforce the statement “We’ll do more than this; this is just the minimum” by pointing out features such as:
- We added ADA features to the graphic so it can be tabbed.
- In addition to the graphic, we added hover text at your request.
- We made the hover text accessible to “assistive technology.”
Writing acceptance criteria is as much an art as a science. It must be specific enough to complete the user story with a few easy-to-understand statements. Properly written acceptance criteria is the keystone of a successful user story!
As ScrumMasters, we all have different styles, we work in different corporate cultures, and we have different team dynamics. So this is just one perspective. I encourage others to comment on this article with their experiences and recommendations.