Acceptance criteria are an essential part of product development. They help you translate requirements, communicate needs, and confirm alignment.
However, they’re not all made equal. There’s a tremendous difference between lazily jotted thoughts and properly refined acceptance criteria.
The latter clearly communicates what needs to be developed. The former often brings only confusion and doubts.
In this article, you’ll learn some tips on how to make sure your acceptance criteria are helpful.
In short, acceptance criteria serve as a checklist for determining whether a given ticket or user story has been fully delivered.
One could say it’s a product requirement document on a task level. It clarifies what the ticket is all about, helps QAs understand what to test, and gives stakeholders visibility into the scope of planned work.
Let me share some of my favorite tips for making acceptance criteria a truly valuable part of the product development lifecycle:
Trust me, if you don’t care about non-functional requirements, the odds are that others won’t, too. And non-functional requirements can make or break a feature. After all, it doesn’t matter how great a feature is if its performance makes it unusable.
Consider areas such as:
Trust me, fixing non-functional requirements after a feature has been delivered is a journey through hell.
Does including non-functional requirements in acceptance criteria mean you need to be super technical? Not really.
Remember that product development is a team sport. As a product manager, your job is to make sure acceptance criteria are there and that everyone is aligned on them, but you shouldn’t be the only person actually writing them.
Your team brings different skills and perspectives to the table, which will help you consider more angles and identify gaps in requirements.
“If it’s not in the acceptance criteria, it doesn’t exist.”
Even though many product people refrain from forcing other stakeholders to go so deep into details, it has more benefits than disadvantages.
It’s a very tangible way of communicating how you plan to achieve desired outcomes and helps avoid misunderstandings and disappointments.
It also tends to raise awareness of how much work is actually required (especially regarding non-functional requirements), which makes answering the ever-dreaded “why is it taking so long?” questions easier.
Walk stakeholders through acceptance criteria on a call. If you just send it to them to review, odds are they’ll either not do it or just skim through it, which defeats the whole purpose.
That one might be a bit controversial, but I like to mark some of the acceptance criteria as optional.
It achieves two main purposes.
First of all, it allows decisions to be delayed until more information is known. Say you are working on an API endpoint and would love to get a response time of 100ms, but you know that the average so far has been 200ms.
Instead of over-refining upfront whether it’s possible or not, I’d write down following acceptance criteria:
This way, the team can decide while working on the ticket if all of the acceptance criteria are feasible and worth pursuing or not if they’re not possible under the given constraints.
They also make further scoping easier… Say you need to speed up development. You can just remove all nice-to-have acceptance criteria without actually rewriting all the tickets.
The most common mistake when it comes to writing acceptance criteria is focusing only on the happy scenario, that is, what should happen when everything goes as planned.
But it doesn’t always go as planned. You also need to think about
What should happen if the user doesn’t finish the intended task properly? The classic example is trying to create a new account without meeting password security criteria. You need an error message and that should be included in your acceptance criteria.
Failure conditions are negative scenarios that happen on the product side. Say you want to create a new account on a website, but the registration API doesn’t respond. You might want to have a fallback scenario or error communication if that happens.
You don’t need to cover every failure scenario, but make sure to consciously decide what to ignore.
Edge cases are conditions that, although rare, still take place.
For example, you might have a Q&A platform where the vast majority of questions have 0-2 answers. However, there might be 0.10 percent of questions that have more than 10 answers — that’s an edge case.
Sometimes, the edge case doesn’t require any additional work, and sometimes, it might call for adjustments. For example, adding paginations or changing the ads configuration.
Similarly to failure conditions, you don’t need to take care of every single edge case out there, just make sure to think about them and make conscious decisions whether to ignore or tackle them.
There are many ways to write down acceptance criteria.
You could write a generic checklist, write tons of user stories or scenarios, or go technical with Gherkin syntax.
All of those solutions are valid, just make sure to stay consistent over time. Sometimes, it’s very tempting to break the format out of pure laziness or time constraints, but believe me, it often backfires.
The more consistent your acceptance criteria, the less room for misunderstanding.
There’s one exception to consistency, though. Even though my acceptance criteria usually take a written format, I sometimes resort to simplifications such as “as in the picture.”
Just imagine converting the following flowchart into a written list of criteria:
Is it possible? Yes. Will it be more precise? Not really. Is it more soul-sucking? Definitely.
Some concepts are just better explained with visuals.
“Wow, that sounds like a lot of effort” is a common reaction I get when describing my process.
I understand where it’s coming from; it’s a lot of work.
First of all, remember that it’s a team effort. Engage designers, developers, and other stakeholders in the process. The PM’s job is to ensure that acceptance criteria are established and that everyone is aligned on them.
Secondly, it’s effort well spent. Investing an hour more into writing acceptance criteria is still a better option than wasting hours pivoting due to misunderstandings or fixing issues after the release just because you forgot about critical edge cases.
Plus, the more you practice writing acceptance criteria, the easier it becomes over time.
Featured image source: IconScout
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, Product, UX, 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.
To help demystify stakeholder management, you can use tools that introduce a structured approach for your product team.
Role-definition frameworks like RACI, RAPID, and RASIC take a structured approach to assigning roles and clarifying accountability.
Jann Curtis talks about understanding your audience’s purpose and what they hope to get from the conversation.
Scaled agile is an approach that allows you to extend agile principles across multiple teams, projects, or business units.
Learn more →
