What are the most common mistakes when writing acceptance criteria?

Acceptance Criteria is often mistaken with the Definition of Done, which is a checklist applying to every task in a project. It is also often confused with User Story, but in an ideal Agile development scenario, every user story needs to have both in it. Acceptance criteria, usually following the Given/When/Then format, specify the conditions a user story must meet to be considered complete. To clarify, a user story expresses a user's need, following the structure: "As a <user>, I want <something> so that <benefit>." Product managers are generally responsible for user stories, but crafting comprehensive acceptance criteria can be challenging for them, as technical insights might be necessary.

In some cases, there can be assumptions on behalf of the development team and provide limited information on the functional behavior of the system. This can range from one-liner statements to copying and pasting user story titles as acceptance criteria. Striking the right balance between too little and too much information can be misunderstood, causing brain drain during sprints. Another scenario is when people are expected to understand requirements based on their project tenure or experience. This can lead to ambiguity, missed deadlines, and longer lead times. It is better to moderate assumptions and provide necessary details for a comprehensive understanding of the system's functional and nonfunctional aspects.

One clue, in my opinion, that the AC or the story as a whole is ambiguous appears at the estimation phase. If the team is unable to reach an agreement regarding the story point, then the AC is undoubtedly unclear to them, leading to varying interpretations among the team members.

One of the most critical mistakes regarding acceptance criteria is believing that they replace the conversations that should take in place not only about them but about the whole user story. User stories are a conversation protocol, preferably face-to-face. Through conversation, we achieve two goals that are difficult, to achieve otherwise, (i.e., writing them and its corresponding AC): 1. Ensure everyone involved understands what the User Story and Acceptance Criteria are about. 2. Ensure everyone has the same understanding. This common insight is crucial when developing an excellent product. So, next time you set out to write acceptance criteria, consider first if you've had enough discussion with the relevant parties about them.

Acceptance criteria should be clear and concise that every stakeholder / team member should understand it clearly. Vague criteria results in ambiguity, different / assumptions / interpretations which may cause conflicts between teams and finally resulting in delay or bad quality.

Teams often make these common mistakes: Vague Language: Ambiguous terms can lead to misunderstandings. Over-Technical Detail: Avoid jargon and specifics best left for implementation. Inconsistency: Uniform format and style prevent confusion. Ignoring Edge Cases: Only focusing on the primary scenario neglects possible issues. Overloaded User Stories: Multiple features in one story can be unmanageable. Solo Writing: Criteria should be a team effort, encompassing diverse perspectives. Static Approach: Acceptance criteria should evolve as understanding grows. Un-testable Criteria: Criteria should have clear, verifiable outcomes. Other mistakes are Lack of Prioritization, Skipping Non-functional Aspects, Unnecessary Repetition, Avoiding Tools.

A lot of Product Managers get confused while trying to create Acceptance Criteria. For PMs to be able to empower Product Specs, they should focus on mainly two components: Context and Implementation. Context = why you're building, who is it for, and principles to follow Implementation = what you're building with key functional requirements By the end of the day, PMs must find the right spot of clarity and alignment around Acceptance Criteria. In other words, if you try to be too prescriptive, the AC will disempower your team. On the other side, if the AC is too high-level, it will also disempower your team.

From my experience of a Technical Product Owner, here are my 2 cents on this. As a team working on the product, we should make sure our acceptance criteria are clear. Vague criteria can cause confusion and slow us down. We work together to state specific, measurable, and testable goals for the development team. For example, instead of saying 'user-friendly,' we say 'the user easily finishes the task in three clicks.' This way, everyone on the team understands what we're aiming for, making sure we deliver a successful product together.

Common mistakes in writing acceptance criteria include vagueness, ambiguity, lack of measurability, assumptions, over-complexity, missing edge cases, and inadequate details. Clear and specific criteria are key to successful project outcomes.

Remember, a PO defines the what and the why; leave the how to the other people that are paid to figure that out. "I want 'X' to display in this corner over here, and be dismiss-able." Your devs can take that in Refinement and figure out a best course of action to accomplish that, while your AC is complete enough for unit tests and QA testers.

Acceptance Criteria either have too much details making it more like a requirement or not enough details misaligning with the Sprint Goal

The acceptance criteria should be owned by the Product Owner (PO) and should be unequivocal to everyone in the team. The team should have a working agreement in place that 'clearly' states what an acceptance criteria looks like. If there is any deviation from that, it should be refined. How much is enough is debatable and hence, letting the team agree upon expectations goes a long way in having acceptance criteria that works.

Excessive acceptance criteria within a user story can overwhelm the team, often leading to instances where team members overlook these criteria. Such occurrences are also indicative of user stories being overly extensive or intricate. More successful instances occurred when the team actively participated in defining the acceptance criteria.

I wholeheartedly agree. Striking the right balance with acceptance criteria is crucial. Writing a user story with overly detailed criteria can inadvertently impose rigid boundaries on developers, limiting their room for creative problem-solving. In my experience, it's essential to collaborate closely with the team to ensure that the acceptance criteria are not only relevant but also reasonable. This involves considering the main functional and non-functional requirements while allowing some flexibility for the development team to innovate within these parameters. It's equally important to maintain a transparent and documented process for any changes to the criteria post-acceptance, and agreed by the end users.

If the acceptance criteria is too long or has too many items PO and the team must check the possibility to slice the story. Moreover, I own freaky call it a mistake as much as to be cautious while writing too many items on the checklist, because it may be detailing every little detail of customer/ business expectations for the sake of the team. It is true though that the challenge is that this may distort people’s focus from the value of the story and people may also mis any of them due to how many they are five. That we have other stories in a single sprint

If a user story is resulting in too many criteria, we may to relook at the user story and its scope and try if it can be divided into more granular user stories. Too many acceptance criteria may be due to getting too deep into implementation details. Looking at the user story, its functional and non-functional requirements at black box level may help to limit the number of criteria.

I always recommend my team to refine the user story until it fits within 1 or 2 lines. If it's overly prescriptive, it resembles a tutorial, and if it lacks sufficient information, it becomes more of a slogan, open to individual interpretation. Conducting sessions to assist engineers and perhaps involving some stakeholders can be highly beneficial. This practice fosters a shared understanding of how to write effective user stories, emphasizing the importance of clarity and brevity. Continuous practice and a willingness to accept feedback are key to mastering this skill.

I advise, write no more than one acceptance criterion up-front, the "happy-path" success outcome. During development (within the sprint) decide how many other acceptance criteria are needed (yes, add them after the team gets the story). Where we choose not to cover a scenario (yet), add that to the product backlog as a User Story (defer acceptance criteria). The Product Owner can prioritize it as appropriate, but let's focus on the main value right now, and deliver that. When deferring acceptance criteria, make them testable as you write them - convert to Acceptance Tests within minutes. This removes ambiguity - but unfortunately doesn't guarantee correctness; ultimately there's no replacement for feedback from users and stakeholders.

I would always prefer my teams to err on the side of 'too many', as then the story can be promoted to an 'epic' containing multiple stories. This also enables dividing an overly-large batch of work so it can fit into sprints.

If you end up creating a lot of acceptance criteria for a story, it’s quite as strong indicator that the story should be an epic. That doesn’t mean your acceptance criteria are wasted, they can be a powerful guide to helping you break the epic down into smaller stories.

Start with just one "happy path" acceptance criterion. The developers get accustomed to asking "what's needed here" (add a test). Where the users say "that's wrong" add a test. Where the Product Owner says "out of scope" add a user story to the backlog for when it comes into scope - defer those decisions until if and when that user story comes into scope. The problem described is one that arises only when the writing of acceptance criteria is happening at a distance from the development of the solution. To make the decisions as the need for them is uncovered, you need all points of view on, or available to, the development team as they work.

Not having the relevant Acceptance Criteria will make the outcome of the Story Absolute and the Sprint Goal will not be achieved

If criteria are determined to be out of scope, they must be documented. Could be a Decision Record, could be linked in this story that "further criteria have been moved to epic/story XXXX"

This mistake mostly happens when you as a Scrum Master (or anyone who is creating the stories) clone the story when you want to create a chain of them. The temptation here is to keep the whole description up there and just change a bit in the AC part, at the end, you have a story with long description and irrelevant AC.

This is a bit of an obvious mistake. I would think teams would recognize this and call it out at the retrospective. A product owner worth their salt wouldn’t let this occur.

In a previous project, I encountered the challenge of poorly aligned acceptance criteria. We had a user story for a new feature, but the acceptance criteria we initially wrote didn't fully align with the user's needs. This led to confusion and delays during development and testing. What I found helpful was involving the product owner and stakeholders early on. We held collaborative discussions to ensure that the acceptance criteria truly reflected the user's perspective and aligned with the story's goals. We focused on clarity, relevance, and consistency. This collaborative approach significantly improved our acceptance criteria writing process.

💡 I'm currently running an experiment with the intent to validate an assumption I have about LinkedIn's Community Top Voice badge. Are you curious about the results of the experiment? All you need to do are 2 steps: 1️⃣ Like this message 2️⃣ Follow me I will publish the results soon. Stay tuned! 🤗

When writing criteria that deviate from the user story, clearly document and communicate them separately. Provide a clear purpose and rationale, addressing any impact on development. Discuss trade-offs and obtain agreement from stakeholders. Regularly review and revise to ensure ongoing relevance, while prioritizing alignment with user stories for delivering value to end-users.

Writing criteria that don't align with the user story is a common pitfall, often encountered by less experienced Agile teams. This situation calls for the ongoing guidance of a vigilant Scrum Master. It's essential for the Scrum Master to work with the team and challenge the Product Owner to adhere to the accepted format, which is typically reviewed and approved by the end users. This approach not only helps in maintaining alignment but also promotes a shared understanding of the user story's intent.

What I have encountered is that there can be more than one persona that must be considered when writing acceptance criteria and that often times leads to different ways of verification and measure. Some teams tend to cast a wide net by writing general verification and measure criteria rather than being specific and that hurts the teams in the long term.

The majority of the Acceptance Criteria should be added when the Acceptance Tests can be written (i.e. when development is in progress). This way, we get feedback on what acceptance criteria are testable - the developers will ask "How can we test that" for unfeasible, ambiguous, unquantified criteria. And running the tests will uncover contradictory tests if not spotted sooner. Use the skills and tools you have, to get best value for effort when working with Acceptance Criteria. This usually implies deferring that effort until later than accustomed. You get to choose.

On a previous team, we had to rely on one particular stakeholder to validate the acceptance criteria on a certain set of stories. His particular knowledge set was intrinsic to the feature's success, so we had him engaged early and often to ensure those items were understood and on track for approval whenever possible.

💡 I'm currently running an experiment with the intent to validate an assumption I have about LinkedIn's Community Top Voice badge. Are you curious about the results of the experiment? All you need to do are 2 steps: 1️⃣ Like this message 2️⃣ Follow me I will publish the results soon. Stay tuned! 🤗

Acceptance criteria can and should be measurable. It is like a vision of a user who wants to have a particular feature in their product and without it functioning how they envisioned it as a feature, it might very well be rejected. I think one of the good ways to track acceptance criteria is to have a Boolean approach where we can assess whether the answer to the question at every criteria being satisfied as written is "True" or "False" and it can help us quantitatively track the progress of delivery.

This is a common issue where acceptance criteria lack verifiability and measurability. When I coach my team, I emphasize that having criteria without metrics is akin to facing a problem, as the Chinese proverb goes, "None of the maps can help if you don't know where you stand." Metrics are crucial for measuring success, and there's no doubt about it. The most effective approach is to break down the user story into the most granular level possible and incorporate measurement standards to ensure that we can precisely gauge the outcomes.

The high probability of this mistake (not verifiable criteria) is for non-functional requirements usability, reliability, scale and performance. This is may not be problem with the acceptance criteria, root cause may the use-case itself which doesn't quantifyable or measurable requirement. Ex: "Ease of use", "Highly scalable" etc

100% agreed. This is why it is so important to link the reasoning behind the acceptance criteria. Transparency is the key to a collaborative mindset.

Esse tipo de situação normalmente ocorre quando, não são utilizando uma metodologia para tomar decisões mais acertivas e sempre trazer o usuário para próximo para fazer parte do escopo e das etapas do projeto

Acceptance criteria are essential for successful products and serve as a roadmap for the QA team. Every user story should encompass validations comprehensively. Evaluating stories against Definition of Done (DOD) and Story Points (SP) can be challenging. A productive method involves breaking stories into smaller parts, aligning them with acceptance criteria and sub-tasks, and defining their DOD accordingly.

Ensuring independence in acceptance criteria is vital for maintaining the modular structure of user stories. One way to achieve this is to introduce a "definition of ready" (DoR) checklist in your team's workflow. This checklist should include criteria for acceptance criteria, ensuring that they are atomic, independent, and collectively exhaustive. This practice can significantly reduce dependency and redundancy issues.

Vagueness: Not being specific enough, leading to ambiguity. Over-complication: Including too many details, making it hard to understand. Omitting Context: Not explaining the user's perspective or motive. Mixing Multiple Criteria: Bundling several requirements into one, creating confusion. Neglecting Non-functional Requirements: Overlooking performance, security, or usability aspects. Not Collaborative: Writing criteria without input from stakeholders, potentially missing key aspects. In essence, clarity, specificity, and collaboration are vital for effective acceptance criteria.

Much like user stories need to be independent, so should the acceptance criteria. This also makes it easier to create test scripts for each acceptance criteria which can be used to confirm stories.

💡 I'm currently running an experiment with the intent to validate an assumption I have about LinkedIn's Community Top Voice badge. Are you curious about the results of the experiment? All you need to do are 2 steps: 1️⃣ Like this message 2️⃣ Follow me I will publish the results soon. Stay tuned! 🤗

As a writer of user acceptance criteria. Given that you are describing engagement with the system to perform tasks that users are familiar with. When you describe the conditions ensure you use the expected or shared language so that unnecessary confusion is not caused slowing your tests down.

These are basic hygiene things around planned work for any team. Teams should be open enough to acknowledge such shortcomings and work them to improve their acceptance criteria. Note that these changes do not happen overnight. However, regular refinement does help.

Este tipo de situação ocorre quando está fora da sintonia com a empresa e usuário, pois nada é independente quando você faz parte de uma Organização.

Acceptance Criteria should be understanable to everyone and should have specific details to achvieve the End outcome of the story

Acceptance criteria is a team sport. Make sure to consider all team members areas and deliverables. And if you see acceptance criteria over and over agin across many stories, consider moving them to a form of definition of done that can be applied to multiple stories.

Acceptance Criteria are an integral part of user stories and should be reviewed in that context. Good user stories follow the simple INVEST plan (Independent, Negotiable, Valuable, Estimatable, Small, and Testable). AC should reflect the INVEST nature of user stories. In short, it is an opportunity to verify what we set out to accomplish in the user story is in fact independent, small, and valuable. This will be very helpful in pursuing outcomes rather than just verified outputs.

Through my years coaching teams, I’ve seen one common mistake that can hinder effective communication and development when elaborating Acceptance Criteria is dependency on implementation. Acceptance criteria should focus on the "what" and "why" rather than the "how." Avoid specifying the technical solution or implementation details, as this can limit the development team's freedom to produce innovative solutions. For example, I’ve often seen incorrect focus on technology. The AC says: "The user story must be implemented using AngularJS and connect to the database using MySQL." When the correct one must be: "The user story should provide a responsive web interface for users to view and edit their profiles and save the changes."

Do not squeeze into acceptance criteria what suits the Definition of Done better. All “acceptance criteria” applying to most of your work belong to the Definition of Done.

Remember that not every acceptance criteria has the same value, and there should be a future release. If you did risk assessment at the beginning and prioritized your requirements, you have also implicitly prioritized your acceptance criteria. That lets you have a reasonable discussion over whether that missing criteria has to be fixed now or can get punted to the next release.

The best way to write acceptance criteria is to make them clear, concise, and testable. They should focus on the user's perspective, be free of implementation details, cover both typical and edge cases, and align with the user's needs and expectations.

Neglecting edge cases in acceptance criteria is a common mistake in software development. It leads to incomplete testing, functionality gaps, and a poor user experience. Edge cases, extreme scenarios that go beyond expected inputs, are often overlooked. This omission leaves the system vulnerable to unexpected issues in extreme conditions. It also omits critical functionalities and requirements, resulting in incomplete features. This oversight harms user experience, causing frustration and eroding confidence. To avoid this, it's necessary to identify and include edge cases in acceptance criteria for thorough testing and robust software performance.