Acceptance criteria is a critical but often overlooked element that can eliminate misunderstanding in Agile development. According to Product Plan’s The 2021 State of Product Management Report, communication is the second skill most product people lack. This deficiency can affect the consensus with cross-functional teams when discussing your product’s success criteria.
Everybody might nod and say they understand the product’s trajectory, but do they really?
With acceptance criteria, you can properly set the expectations around your product’s user stories and functionalities. More importantly, it eliminates guesswork, ensuring all team members and stakeholders are on the same page about the product.
Table of Contents
- What are the acceptance criteria?
- Who writes acceptance criteria?
- Acceptance criteria vs. user stories: What’s the difference?
- When should you write the acceptance criteria?
- Why write acceptance criteria?
- What should be included in the acceptance criteria?
- Types of acceptance criteria
- How to write the acceptance criteria
- Common challenges when writing acceptance criteria
- Examples of acceptance criteria
- Ready-to-use acceptance criteria templates
- Afterthoughts
- Choosing The Right Gamification SaaS: A Buyer’s Handbook
- How Would A Digital Product Manager Benefit From Gamification?
- 6 Benefits Of Gamification To Your Product
- How to Make Tracking KPIs Fun And Productive With Gamification
What are the acceptance criteria?
Acceptance criteria are detailed specifications that define when a product is considered complete and ready for release. They act as a roadmap stating what success looks like for a specific task or user story in a project.
It typically follows a “Given-When-Then” formula outlining the starting conditions (Given), the action taken (When), and the expected outcome (Then). This format bridges the gap between a product manager’s vision and the work the development team should do. And by doing so, everyone involved clearly understands what needs to be done.
Writing acceptance criteria is essential for avoiding surprises and aligning teams towards a centralised product vision. More importantly, it aims towards delivering a minimum viable product that meets and exceeds user expectations.
Who writes acceptance criteria?
The role of writing acceptance criteria isn’t tied to a single role because the project’s dynamics and goals frequently change. While product managers often lead the way in defining them, it’s essential to understand that it’s not their sole responsibility. Depending on the situation, the product owners, developers, or requirements analysts can take on this position. Moreover, clients well-versed in technical and product documentation may document the user acceptance criteria themselves if needed.
Product owners shouldn’t always be the ones to write acceptance criteria
In reality, it’s common for product owners to write acceptance criteria as a part of the product backlog. But since they’ve already got a lot going on, it’s impractical to rely solely on them when making these requirements.
The better alternative is encouraging the development team to contribute to the feature’s purpose and outcomes. This approach enhances clarity and enables the product owner to confirm alignment between the team and the intended feature. In essence, writing the acceptance criteria can be a joint effort between the development team and the assigned writer.
This approach provides a more holistic perspective and insights, leading to better-documented acceptance criteria. Effective communication and teamwork are crucial to aligning these criteria with user experience and project objectives.
Acceptance criteria vs. user stories: What’s the difference?
While acceptance criteria and user stories are intimately related, they are different and serve distinct purposes in product development. Let’s learn the key differences between the two.
User stories are concise narratives that capture a specific piece of a product’s functionality from the user’s perspective. They focus on who the user is, what they want to achieve, and why it matters.
In contrast, acceptance criteria provide the nitty-gritty details that specify how a user story should function. They outline the conditions, parameters, and outcomes that must be met for the story to be considered “done”.
While user stories encapsulate the “what” and “why” of a feature, acceptance criteria dive into the “how” and “when”. Each serves different functions, ensuring a shared understanding among team members about the specifics of implementation and testing.
When should you write the acceptance criteria?
The timing of writing the acceptance criteria is critical in agile development. And because of this, the process should start early and continue iteratively throughout the product’s lifecycle.
It’s okay for imperfect initial criteria that surface during the backlog refinement. Just make sure that these requirements are solidified before the development begins. This “just-in-time” approach ensures the acceptance criteria reflect the latest information needed for product development, including customer goals.
The ideal time to finalise the user story acceptance criteria is during sprint planning. During this time, the team can review them to resolve any uncertainties and misalignment with sprint goals. If you wait until development, you risk focusing on the team’s perspective instead of the customer’s intent.
Why write acceptance criteria?
Acceptance criteria help product managers and their teams ensure clarity, efficiency, and risk mitigation during development. Some other c
#1. To define boundaries
Acceptance criteria act as guard rails that define the scope and limits of your product’s functionality. Such restrictions are critical to be set in place before the team gets working on a specific user story. It leaves no room for ambiguity so your team can precisely understand what the product should and shouldn’t cover. As a result, it eliminates guesswork and ensures everyone shares the exact expectations even before the development process starts.
#2. To identify and mitigate risks
Acceptance criteria can also serve as an early warning system to help spot and mitigate risks. They enable product managers to identify pitfalls and challenges before they even escalate into costly surprises during the development cycle.
For example, specific acceptance criteria may require the app to detect weak passwords and prevent user progression. You can set this to address negative scenarios like incorrect data input or unexpected user behaviour. Ultimately, it specifies how the product should respond to certain situations so potential issues that may arise are quickly addressed.
#3. To reach consensus
As a product manager, you know how difficult it is to bring everyone on the same page. With acceptance criteria, you can achieve consensus among stakeholders, developers, and designers, to name a few. Making decisions will become much more manageable when everyone agrees on success criteria.
More importantly, these criteria align the development teams with the client or product owner’s expectations. When this happens, deliverables will be clearer, and it will be easier to anticipate project outcomes.
#4. To avoid scope creep
Scope creep is the bane of every product manager’s existence. It flies under the radar to distract teams and waste valuable resources to fulfil the product’s strategic goals. With acceptance criteria, you can set clear boundaries for what’s in and out of the project scope.
#5. To streamline acceptance testing
When done correctly, acceptance criteria can streamline your acceptance testing by ensuring all requirements are met. This will eventually translate into faster and more accurate testing. These benchmarks establish a precise “pass or fail” standard to enhance the overall quality of the product during user story acceptance testing.
What should be included in the acceptance criteria?
Acceptance criteria differ from product to product. Regardless of the differences, acceptance criteria must describe what the product does and what users can expect. Moreover, they should also account for the specific needs of developers and testers.
Here are the three main things that must be included in acceptance criteria:
- Functional criteria– the conditions a product must meet.
- Non-functional criteria– conditions the final product must meet that aren’t necessarily actionable.
- Performance expectations – these include response times, load handling, or data processing speed.
Acceptance criteria should be succinct, concise, and straight to the point so it can stand on its own. It must also never be a revised version of user stories or other design documents.
Types of acceptance criteria
#1. Scenario-oriented acceptance criteria
This type of acceptance criteria describes how the product should behave in specific situations and scenarios. These criteria are approached using the Given/When/Then (GWT) sequence, which looks like this:
- Given some preconditions…
- When I do some action…
- Then I expect some results.
The scenario-oriented acceptance criteria is a more comprehensive and structured GWT approach borne from behaviour-driven development (BDD). This is what the acceptance criteria would look like if they followed this format:
- Scenario – Describes the behaviour in to be detailed
- Given – Sets the initial state of the scenario
- When – Specifies the user’s action
- Then – Defines the expected outcome of the user’s action
- And – Further continuation of the previous statements (if needed)
This format can also guide testers on when to start and end testing for a specific feature. It’s a favourite among agile teams because it effectively fulfils requirements and facilitates manual and automated acceptance testing.
#2. Rule-oriented acceptance criteria format
There are many instances where the GWT structure is impractical, such as:
- A user-story that describes a system-level functionality
- The development team doesn’t need in-depth test scenario details
- GWT scenarios don’t fit a feature’s described design and user experience constraints.
The best alternative to use in these cases is the rule-oriented criteria format. It resembles the documentation in traditional Waterfall development scenarios where each expected function is listed individually. This format defines the conditions and constraints to be met for a feature to be considered complete. And since it’s technical, this format is highly effective for precise logic.
#3. Other custom formats
All the acceptance criteria formats mentioned above can accommodate most user stories. However, there are certain cases where clients or product owners require customised acceptance criteria. When this happens, you can invent your format to avoid misunderstandings, given that it’s clear and written in plain English. Remember that the exact format largely depends on the client and development team’s preferences and requirements.
How to write the acceptance criteria
#1. Understand the user story
Before you start writing the acceptance criteria, you’ll need a thorough understanding of the given user story first. User stories usually follow this format:
As a [USER], I want a [FEATURE] so I can [BENEFIT].
For instance:
As a busy entrepreneur, I want a fitness app that provides pre-designed workout routines to maintain an active and healthy lifestyle.
An in-depth understanding of the user story will give you a foundation to work on when writing good acceptance criteria. To do this, you can engage with the product owner or stakeholders to gain a clearer perspective of the users. Get into detail with what they need, what motivates them, and the problem the feature aims to address.
#2. Start with a clear goal
Ensure you have a clear and concise goal before writing the acceptance criteria. Ask yourself this question:
Do you know what success looks like for this user story?
Remember that this goal must be in alignment with the broader objectives of the product.
#3. Choose an acceptance criteria format
While the “Given/When/Then” is widely used by many product teams, there might be other better options to consider. Depending on your needs, you can either use other formats like “As a [user], I want [feature], so that [benefit]” or simple bullet points as alternatives. The key here is to choose a suitable format to enhance comprehension and communication within your development team.
#4. Be specific and testable
Always avoid vague language or ambiguous terms whenever you write acceptance criteria. Doing so can lead to miscommunications, conflicts, and confusion. Do your best to write each criterion describing functionality that can be tested to ensure it meets the desired outcome. More importantly, always use quantifiable terms whenever possible.
#5. Include edge cases
An edge case is a scenario or situation that reveals unexpected behaviour or vulnerabilities in a system. These scenarios are rare, but addressing them is still critical to the completion of the product. Use your edge cases to determine the capacity of your system beyond what it can support. By doing so, you can identify your product’s weak points and address them ahead of time.
#6. Collaborate with the team
Remember that writing acceptance criteria is collaborative, and you shouldn’t do it alone. To write effective acceptance criteria, you’ll need the help of key professionals, such as developers, designers, and quality assurance engineers. Their insights and expertise are critical in ensuring the criteria are technically feasible and comprehensive.
#7. Prioritise and validate
Your acceptance criteria must be based on your user’s needs and project goals. To do this, you’ll need to consider the critical aspects of the user story first. Then, validate your criteria by comparing them against user expectations and the overarching product objectives.
#8. Review and revise regularly
As mentioned earlier, writing the acceptance criteria is an iterative process that evolves alongside the product. It may change as you gain new insights, user feedback, or encounter changing requirements. And because of this, you must be prepared for revision to ensure they remain relevant and accurate.
#9. Keep it concise
Acceptance criteria should be free from any unnecessary complexity; they must be simple and easy to understand. Each acceptance criterion must have a clear Pass/Fail result.
#10. Provide examples
Simple explanations are sometimes not enough, so you’ll need to prepare concrete examples to clarify your acceptance criteria. These examples will show your development team what behaviour to expect so there’s no room for misinterpretation. They also serve as practical references for stakeholders to ensure their and the development team’s expectations align with the user’s.
Common challenges when writing acceptance criteria
Writing acceptance criteria might seem easy, but you’d be surprised to realise how challenging it is. You’ll need to know the common pitfalls to avoid when writing these criteria to succeed in this effort.
#1. Not writing the criteria before the development
You might think that starting the acceptance criteria down the line is a good idea, but it’s a temptation you must avoid. You must establish these requirements from the start to ensure clarity and consensus on your product goals. Failure to do so can lead to misunderstandings and misalignment among team members regarding the user’s needs.
#2. Using passive voice and negative phrasing
Acceptance criteria should be conversational and free from passive voice and negative phrasing. Instead, you can use active and positive sentences that clearly express user expectations and desired outcomes.
#3. Narrowing down too much
Remember that the criteria focus on the result (what), not the approach to the solution (how) – but don’t do it too much! An overly narrow acceptance criteria can limit your team’s flexibility and hinder their ability to explore alternative solutions.
#4. Getting too broad
Conversely, you shouldn’t write broad acceptance criteria either. Good acceptance criteria establish a concrete boundary so developers know where to stop. Therefore, they should balance being specific enough to guide the development and broad enough for some manoeuvrability.
#5. Getting too technical
The idea behind acceptance criteria is to communicate when the product is ready to be released effectively. Filling them with jargon and too much technical language is counterproductive and confusing. Instead, the criteria should be written in plain and understandable language so all the stakeholders can grasp them.
#6. Not making the acceptance criteria measurable and testable
The acceptance criteria must be measurable to ensure effective planning and estimation. It must also be written to allow testers to verify if all the requirements have been met. Ensuring the criteria are testable will significantly reduce ambiguity on the part of developers and testers.
#7. Not reaching consensus
At the end of the day, all stakeholders and team members must agree on the proposed acceptance criteria. This must happen to ensure that everyone is aligned and agree upon what problems need to be solved. Different perspectives will inevitably lead to different solutions, which can be problematic later in development. This must happen to ensure that everyone is aligned and agree upon what problems need to be solved.
Examples of acceptance criteria
Here are some well-made examples to give you a better idea of what acceptance criteria should look like.
Example #1: Using the scenario-oriented acceptance criteria
USER STORY: As an e-commerce customer, I want to track the status of my order to stay informed about its delivery progress.
SCENARIO: Accessing Order Tracking
- GIVEN: The user logs into the e-commerce platform
- WHEN: The user accesses their account dashboard
- AND: Clicks on the “Order History” or “Track My Order” section
- THEN: The system allows the user to view a list of their recent orders
- AND: The system gives the user an option to track the status of each order
Example #2: Using the rule-oriented acceptance criteria format
USER STORY: As a patient, I want to be able to schedule appointments with doctors in the healthcare app with specific rules and constraints to ensure efficient scheduling and avoid conflicts.
RULES:
- Patients should be able to request appointments with specific doctors from within the app.
- Appointment requests must include the preferred date and time.
- The app should check the doctor’s availability for the requested date and time.
- If the doctor is unavailable, the system should suggest alternative slots or ask the patient to choose a different doctor.
- The system should prevent patients from scheduling overlapping appointments with the same doctor.
- Patients on the waiting list should be notified when an appointment slot becomes available due to a cancellation.
Example #3: Custom acceptance criteria format
This is an example of customised acceptance criteria to identify strong passwords.
Writing acceptance criteria is deceptively challenging despite how simple it looks. To make the process easier, follow these tips and best practices when writing effective acceptance criteria.
Ready-to-use acceptance criteria templates
The examples and tips above help you create acceptance criteria for your product development process. But if you still need help, you can use ready-to-use templates to ensure user stories are implemented appropriately.
Below are some of the best templates we’ve found.
- Aha! – Validation Criteria Template
- Stakeholder Map – Project Requirements Gathering Template
- Klariti – Acceptance Criteria Log Template
- Powerslides – Quality Standards Template
Afterthoughts
A well-written acceptance criteria eliminates the guesswork present when developing a minimum viable product. They are essential to ensure the organisation delivers a product that meets and exceeds user expectations. However, creating them is easier said than done, requiring team and stakeholders’ collaborative effort to finish it. But once carefully crafted, you can use it to guide the product development process toward an agreed-upon product vision.
At Mambo.io, we strive to help product managers address user engagement challenges through gamification. Our platform can help you actively engage and motivate your users to produce the outcomes you desire. Book a demo today to discover how gamification can solve your engagement challenges!
