Everyone wants to go Agile today. Teams want to put the user in the centre of their product development process while building products. After all, you are building the product for your users, right?
To do this, teams write user stories as a way to keep the user in mind while defining the product and its features. And to ensure the team meets the standards their users expect, teams write acceptance criteria for each user story.
It is easy for teams to neglect acceptance criteria as being simple.
However, they're used to document customer expectations, provide an end-user perspective, clarify requirements and prevent ambiguity. When done properly, this will eventually help your quality assurance verify if the development goals were met.
In this article I will talk about some of the common mistakes teams make when writing user stories.
1. They are too broad
Writing acceptance criteria too broadly defeats the fundamental purpose of its existence. While they should not be confused with test cases, acceptance criteria should communicate what specific conditions should be met to ensure that when a user story is completed, it meets a certain standard.
2. Does not consider the user experience
A good product is table stakes today. And that doesn't mean spewing features one after another, but building products and features that provides good experiences at every touch point. This makes user experience more important than what it was before.
If your acceptance criteria doesn't take into consideration the end-user experience, you're most likely missing out on a huge opportunity to satisfy your customers.
3. Writing about the "how" instead of the "what"
Yes, acceptance criteria should be specific and concise. But that shouldn't make you get too specific that you end up talking about the implementation details of how you're going to go about it.
Remember, at the end of the day, acceptance criteria are a set of criteria that needs to be satisfied. If they include "how" your team should implement a user story, you are in a way micromanaging them. By keeping things simple and talking about the "what", you give your team the opportunity to explore, get creative, and come up with solutions to solve the problem at hand.
4. Writing acceptance criteria as you build
Although acceptance criteria is usually written by the product owner, it can be written by anyone in the cross-functional team. Sometimes, I've noticed dev teams take this a bit too far by writing acceptance criteria while they're building the feature. The problem with this is, it doesn't keep other members aligned on this criteria and can lead to mismatch in expectations. It's essential for teams to ensure they write acceptance criteria before the sprint begins — ideally before the sprint planning meeting.
5. Having assumptions
It can feel silly to write an acceptance criteria that you think is kind of obvious. But what's obvious for you, need not necessarily make it obvious for your team. Building products and features is a cross-functional effort. That means, people come with different perspectives that others don't know. Writing even the most obvious acceptance criteria can help your team give the complete picture of what needs to be done and help remove inefficiencies in your development process.
Conclusion
Your agile tool might help you writing acceptance criteria with a template. But it is never as simple as completing a fill-in-the-blanks form.
The individual impact of inefficiencies in your product development process is almost always invisible. One mistake while writing an acceptance criteria often leads to a series of other mistakes. And the worst part is, it is nearly impossible to trace it back to a poorly written acceptance criteria.
Top comments (1)
Great insights on acceptance criteria pitfalls! Your breakdown of common mistakes is valuable, emphasizing the importance of clarity and specificity. For those looking to enhance their understanding of acceptance criteria, your article serves as a helpful guide. If readers want a deeper dive into acceptance criteria definition, exploring real-world examples and collaborating with stakeholders can further strengthen their approach.