Acceptance criteria is essential for when you write user stories. They help your team understand what's essential and what they should focus on while developing a feature.
Let's jump in and look at acceptance criteria in-depth.
What is an acceptance criteria?
Acceptance criteria let you define when your user story is complete and when a user story has all the functionality needed to meet your user’s needs.
They are a set of conditions a user story should satisfy to be considered as done. It provides a detailed scope of the user story and what is needed so your team can understand what they’re up against. That way, every time you ship a new feature, you can be sure the feature meets the standard your users deserve.
But before you enthusiastically declare a set of functional criteria that should be met for your user story, consider how other variables can impact the quality of your feature as well and include them into your acceptance criteria.
Acceptance criteria can include details like
- User experience
- The current user story’s effect on existing feature
- A key performance like speed
- What the user story was intended to do
So, based on the feature you are building and its complexity, sit together with your team and figure out what minimum subset of functionality it should perform and how it should behave.
If it’s complex or a core feature of your product you should consider writing as many and detailed acceptance criteria as possible to help your team avoid any confusion.
How to write acceptance criteria for user stories?
1. Acceptance criteria should be written from a user's perspective
Acceptance criteria is a way of looking at the problem from a customer’s standpoint. It should be written in the context of a real user’s experience. After all, you are building your product for your users, right?
2. Criteria should be clear and concise
Acceptance criteria should not be confused with test cases nor with documentation. It is important to keep your criteria as simple and straightforward as possible.
3. Everyone must understand your acceptance criteria
Your criteria is useless if your developers can’t understand it. If you’re unsure about whether something is clear, take the time to ask and make adjustments until things are clear.
4. Acceptance criteria is not about how. It's about what
Like user stories, acceptance criteria is not a task. They are a technique for communicating about the user story.
5. Acceptance criteria are specific, but are not another level of detail
Consider a tax filing software. The most important requirement is that it correctly calculates the due tax when incomes and expenditure are given. Obvious, right? And you know you won't be able to test all possible combinations either. Because the possibilities are nearly endless.
So your acceptance criteria for the user story will specify specific conditions, or what conditions must be satisfied. That means being more specific and not adding another level of detail. This helps your team understand what's required and ship faster. And of course, you might see some improvements when you compare your current burndown chart with the previous ones.
6. Acceptance criteria can be a restatement of user story from a user's standpoint
This is applicable only if the user story isn't all too complex. Here's an example of what I mean by that.
For a user story like “As a finance officer I want to be able to accept an invoice so that I can keep a track record of all my financial statements”.
The acceptance criteria for it is as simple as “When I perform the accept action, the invoice is accepted (check by examining the record for the invoice)”.
Given/When/Then acceptance criteria template
To make life easier, here’s a simple template you can use for writing acceptance criteria:
Given [context] when [a specific action is performed] then [a set of consequences should occur]
Sample examples of acceptance criteria
For the example user story:
"As a writer, I want to receive notifications when others add comments so that I am up-to-date."
Here are three examples of acceptance criteria for the above user story:
- Given I don't have app open when my phone is locked then I should receive a banner notification.
- Given I have the app open when I am writing on the doc then the bell icon should update to show unread notifications with count.
- Given a user was mentioned in a comment using @ mention when the mentioned user is reading the comments then a flash message should show up on the same comment thread with a message notifying about the new comment.
It's recommend users to add all acceptance criteria as a description to the user story, so when your team members pick it up, they have the full picture of what’s required to complete the user story and its related discussions all in one place.
Who writes acceptance criteria?
Pretty much anyone on the cross-functional team can write acceptance criteria for user stories.
Most of the times it is the product owner or the product manager who writes the acceptance criteria because it is important to write it from a customer's perspective. And who better to do that than them?
When should you write acceptance criteria?
It isn't uncommon to write the acceptance criteria for a user story while grooming the backlog just before their Sprint Planning ceremony. That way, they can bring it to the team during the Sprint Planning meeting to discuss the priorities.
Many people, however, like to discuss priorities before writing the acceptance criteria since priorities can always change based on new learnings. And by writing acceptance criteria once it has been prioritized, teams get to reduce this uncertainty and not spend time on things that aren't a priority.
This, however, isn't the right approach. While it gives the notion that you are spending time on a prioritized list of user stories, not having the acceptance criteria before prioritizing can hinder progress.
After all, you need all the available information at your disposal to prioritize effectively.
Oldest comments (0)