User stories are a critical element of the agile software development process. But they’re so different from traditional software requirement documents that many Scrum teams struggle to get them right. And not surprisingly, teams often also struggle to determine user story acceptance criteria.
Creating your list of user stories – called the product backlog – consists of the following steps:
- Identify user roles
- Brainstorm features for each role
- Expand features into user stories
- Add acceptance criteria to the user stories
In this post, I’ll focus on that last step: adding user story acceptance criteria. I’ll explain what acceptance criteria are, how to write them, and how they provide a foundation for everyone on a Scrum team to understand when a user story is “done.”
What are user story acceptance criteria?
Think of your acceptance criteria as a high-level checklist of what each user story needs to accomplish (once it is fully coded and tested). These are the boxes that need to be checked off before the product owner can sign off on the user story as “done.” Some acceptance criteria describe:
- The functionality expected.
- Constraints and restrictions that need to be in place.
- How the feature needs to connect with other data and features.
- An expected level of performance.
Where do these criteria come from?
Most of the acceptance criteria will come from the Scrum team’s discussion of the user story. This is where the real understanding takes place. These team discussions create a depth of shared knowledge that will help the team decide how to accomplish the story’s goals.
Instead of being a transcript of those discussions, acceptance criteria are simply reminders of the most critical pieces of information. These are the high-level requirements the team decides must be in place for the user story to be complete.
Business stakeholders from a variety of departments will share their functional needs. These stakeholders do not contribute directly to the team discussions, but have their voice through the product owner (who is also in charge of the product backlog). The product owner then ensures that the acceptance criteria outlines those fundamental requirements that will satisfy her—and by extension the business stakeholders’—needs.
Why is acceptance criteria important?
Without acceptance criteria, the development team would have a difficult time putting a user story into action. They wouldn’t be able to distinguish between the “must have” and the “nice to have” bits of functionality. In this way, acceptance criteria provides a “lowest common denominator” of what must be included. It doesn’t define all aspects of the story, or even limit it. All it does is list the absolute minimum requirements for success.
The Scrum team relies on the acceptance criteria to help create their estimates for the tasks required to code and test the story. Again, acceptance criteria are not meant to be narratives or the sum total of the story. Viewing the acceptance criteria should simply help the team make sure that everything important is included in their estimate.
The team also relies on acceptance criteria to determine when the work for that story is completed. The product owner is in charge of accepting or rejecting the story and will only sign off if all the acceptance criteria are met.
An Acceptance Criteria Example
Consider the following user story:
As a Shopper I want to create a gift registry to save a list of products I’d like to have.
A valid set of acceptance criteria for that story might look something like this:
- I can create one or more gift registries
- I can add a product to a registry
- I can specify a quantity desired
- I can view my registry
- I can share my registry with friends and family
- I can remove products from my registry
- I can rename my registry
With this additional information, everyone can understand what’s required for functionality in order for the product owner to be happy. It doesn’t say what the registry needs to look like, or what product details need to be included – those things come from the Scrum team’s discussions (perhaps even attaching cell phone pictures of their whiteboard discussions). The acceptance criteria specify the essential elements that need to be there for the gift registry story to be complete.
Developing Your User Story Acceptance Criteria
If you were a user of the feature in question, what are some of the things you would try when you received the completed, shippable story from the development team? Involving the entire Scrum team in this discussion helps identify the important items by considering a variety of perspectives. It also serves to “program” the subconscious of every team member, making them focus on the essential factors that will streamline their efficiency.
Using a format that starts with “I can” helps put yourself in the end user’s shoes. It also keeps the criteria objective, making it easier for the product owner to determine if it was accomplished or not.
Avoid adding too much detail when writing your acceptance criteria. The goal here is to create a simple checklist, not to go back to the waterfall approach with pages of documentation for every feature. Instead, shoot for five to ten bullet points, plus any technical reminders the development team wants to record to ensure they’re not forgotten.
For example, the development team might say, “I think we could use the XYZ library for this,” while they’re discussing the story. If the story won’t be worked on for a while, it’s a good practice to record that note for the team’s reference down the road.
These guidelines should cover the essentials for most user stories while preventing you from getting down into the weeds.
Acceptance Criteria for Performance and Compliance
Any performance requirements you might have for a story should be included in its acceptance criteria, too. For example, if a story for searching a list of products needs to handle ten million individual products and return results within three seconds, that’s a pretty important piece of information. It could be an expectation from current users, or it could be a requirement to match – or beat – the competition. Either way, the feature won’t meet the needs of the business without it.
That’s the sort of thing the development team needs to know, and should be added to the list of acceptance criteria. Otherwise, the development team will likely make it work and work well, but they might not ensure it works at that specific level of performance.
Legal compliance issues usually translate into acceptance criteria. Business and organizational policy issues are things to look for, too.
How to Review Acceptance Criteria during the Estimating Process
The very first step in estimating a user story involves its acceptance criteria; the product owner reads the user story sentence and reviews the acceptance criteria with the development team.
This information lets the development team understand what’s expected as an output or capability of the user story. The team’s estimate must take each of the acceptance criteria into account, with appropriate story point values assigned to accomplish all of them.
Some acceptance criteria (such as the performance example above, or legal compliance statements) might impact how the task will be implemented. This might eliminate easier or quicker methods under consideration… which will definitely affect the choice of solution and, as an extension, the story point estimate the development team assigns.
When to Add User Story Acceptance Criteria During a Sprint
The simple answer to this would be: never.
Once a sprint starts, product owners often think of additional acceptance criteria that would be nice to have in a story. Or the development team thinks of some “cool” add-ons that would make the story even better. If these were not discussed during sprint planning, do not add them to the story. This would be adding scope, and it would throw off all your carefully planned estimates, timelines, and priorities. Plus, it would break one of the most important Scrum guidelines, which is the scope of a sprint can’t be changed once it starts.
Instead, consider adding these nice-to-have afterthoughts as new stories in your product backlog. The product owner can then decide if those enhancements are worth prioritizing over other features – which is exactly what you’d be doing if you expanded a current sprint to cover them.
It’s up to the ScrumMaster to ensure the Scrum team follows this guideline. As both the owner of the Scrum process and the one who protects the development team from interference (including from excited product owners who might want to bend the rules), the ScrumMaster should always fend off changes to existing sprints. As our Ascendle Scrum teams like to say: “When in doubt, leave it out!”
Using Acceptance Criteria to Aid an Off-Track Team
Sometimes, if a team is struggling to meet their objectives during a sprint, you can split user stories by their acceptance criteria.
I said above that scope can’t be added to a sprint once it starts. But if the development team is getting hung up on a portion of a story and that is threatening their ability to get other stories driven to “done,” there’s no problem with the product owner de-scoping the portion of functionality that’s causing trouble. This allows the development team to keep their heads down and get the rest of the stories done, then regroup once the sprint is over to come up with a strategy to tackle whatever was bogging them down.
In this way, you can “peel off” one or more of your acceptance criteria, which would then be placed in a subsequent user story. The original story can be “checked off” by the product owner, the sprint completed, and the new story can be prioritized as high or as low in the backlog as the product owner feels is justified.
Keep in mind that some acceptance criteria can’t be peeled off in this fashion. A feature lacking legal compliance, for example, could not be considered “shippable.” But most performance criteria could be split into separate stories. In the gift registry example above, the sharing and renaming criteria could be split into a new story and the remaining story would still be “shippable” – even if it didn’t do everything normally associated with a registry yet.
Eager to learn more about user stories? Check out Writing User Stories: It’s Not as Difficult as You Think
Helping Your Team with User Stories
User stories are a big part of what makes agile development so successful. And a big part of user stories – perhaps the biggest part – is their acceptance criteria.
Contact us at Ascendle today to discuss your scrum team needs.
