Almost every PM and product backlog owner uses acceptance criteria in one way or another. They help us clarify requirements, give directions, and provide a checklist when reviewing the final work item.
However, acceptance criteria are not made equal. There are various ways they can be used. I distinguish two primary acceptance criteria types: prescriptive and guiding.
Let’s dive deeper into how you can use them to build better products.
Jump ahead
- Prescriptive acceptance criteria
- Example of prescriptive acceptance criteria
- The purpose of prescriptive acceptance criteria
- Guiding acceptance criteria
- Example of guiding acceptance criteria
- Combining guiding and prescriptive acceptance criteria
- Acceptance criteria vs. the definition of done
Prescriptive acceptance criteria
When someone refers to acceptance criteria, they usually mean prescriptive acceptance criteria.
You can think of them twofold:
- They serve as a detailed requirement list
- You can use them as user stories broken into smaller pieces
Example of prescriptive acceptance criteria
Let’s take a look at an example of prescriptive acceptance criteria.
Story: Transfer premium points
Acceptance criteria:
- A primary CTA button with text saying transfer points on the homepage.
- When a user clicks the button, they see a points transfer modal, which includes:
- A friend dropdown list (mandatory)
- An add a friend button.
- A field for the number of points (mandatory)
- A send button
- A cancel button
- A user chooses a friend from a dropdown list
- Users can input between 100 and 1000 points to the field
- If they do not have enough points, show an error modal
- If they input too few or too many points, show an error modal
- When they click send, validate if all fields are correct
- If not, throw a standard validation error
- If yes, show another are you sure? modal
- Clicking yes finalizes the transfer.
- Clicking no moves the user back to the points transfer model
- After finalizing the transfer, add the transaction to both the sender and receiver history, titled: Points transfer: {amount} from {userID} to {userID}
The purpose of prescriptive acceptance criteria
There are numerous reasons to use acceptance criteria in your product development work. The most common ones include:
Managing expectations
Acceptance criteria help manage expectations, between both the PM and the product team and the team and stakeholders.
They define precisely how a given feature will work. If your “I want to log in” user story has a “log in with Google” option in the acceptance criteria, that builds clear expectations that users will be able to log in with Google, but perhaps not necessarily with Facebook.
Good acceptance criteria leave no room for misinterpretation.
Managing scope
Who’s never had to cut scope to meet a deadline? Throw a rock.
Acceptance criteria help PMs with scoping activities, both when it comes to adding and removing the scope from the initiative. After all, you probably can’t remove the “I want to log in” user story, but you can strip it off fancy acceptance criteria and leave bare basics.
Acceptance criteria help you manage scope in a more granular, scalpel precision.
Serving a basis for estimates
The vaguer the estimation object, the vaguer the estimate. Acceptance criteria provide the so-much-needed details to make development estimations more precise. After all, one could spend an hour or a week working on the “I want to log in” story, depending on the exact details of the login process.
Learn more →Serving as input to test plans
Acceptance criteria serve as valuable input to the QA teams when it comes to preparing test cases. With properly-written acceptance criteria, they know exactly what to test and how a given functionality should work. Otherwise, they would probably need to ask the team, “is it a bug or a feature?” questions all the time.
Guiding acceptance criteria
At a certain level of the product team’s maturity, detailed descriptions of solutions are not only unnecessary, but often very limiting.
In such cases, writing acceptance criteria in the form of high-level, general objectives might be wiser.
It’s all about giving the team a high-level direction and letting them figure out the rest.
Example of guiding acceptance criteria
Story: Transfer premium points
Acceptance criteria:
- A user should be able to transfer up to 1000 points to a friend’s account
- The process should be easy and UX friendly
- Don’t overcomplicate. Let’s try to make an MVP within one sprint
- Include mechanics that prevent accidental points transfer
- Document and store all transfers
Such a description gives enough details to provide boundaries for the initiative while giving the team the ownership to define the exact detail. At the end of the day, product teams are best-equipped to determine the actual solution, and product managers should do all we can to empower them to do so.
Combining guiding and prescriptive acceptance criteria
Different types of acceptance criteria have different uses for the product team.
Guiding acceptance criteria works well as a form of high-level boundary. Bring the problem to the team, let them discover potential solutions, and once you decide on a direction, set boundaries for the solution based on business needs and constraints.
Subscribe to our product management newsletter
Get articles like this to your inbox
Then, as the team defines the details of the solution (sometimes consulting with the product managers, sometimes autonomously), let them write more detailed, prescriptive acceptance criteria that will help them to manage expectations and scope.
Ultimately, it’s not guiding OR prescriptive acceptance criteria. Both of them serve different purposes at different stages of solution development.
Acceptance criteria vs. definition of done
One of the common confusions is the difference between acceptance criteria and the definition of done.
Although they serve a similar purpose, there’s one big difference. The definition of done is shared by all user stories, while acceptance criteria are story-specific.
The definition of done is shared by all user stories, while acceptance criteria are story-specific.
Also, acceptance criteria usually work as a development checklist, while the definition of done works as a holistic process checklist.
In other words, acceptance criteria includes things that should be built as a part of the feature, such as the “log in with Google” and “email me a magic link” features.
At the same time, the definition of done describes the whole journey of the user story (such as developing, testing, writing documentation, performing stress tests, and whatever is part of the definition of done).
Only when both acceptance criteria and definition of done are fulfilled, the story is fully complete.
Conclusion
There are two types of acceptance criteria.
Guiding acceptance criteria serve as a high-level direction and boundaries for the product team. Prescriptive acceptance criteria serve as a more detailed checklist that helps manage expectations and scope, estimate tickets, and plan test cases.
Less mature teams usually receive requirements with a predefined set of acceptance criteria. Once the team matures, though, they write their own acceptance criteria based on the problem they are solving and high-level guiding acceptance criteria.
Although acceptance criteria are similar in concept to the definition of done, while the former relates to a shape of a specific story, the latter defines the journey every user story should go through as a part of the development process.
Featured image source: IconScout
LogRocket generates product insights that lead to meaningful action
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
