A Beginner’s Guide to Acceptance Criteria: Crafting Clear and Effective Criteria for Agile Success
Learn how to write good acceptance criteria for user stories or backlog items
Introduction: What are Acceptance Criteria
Acceptance criteria are crucial in agile methodologies. They define what “done” means for a particular feature or user story or backlog item, ensuring everyone involved has a clear understanding of the expectations and requirements.
They are a set of conditions that must be accepted by the product owner. They serve as a bridge between the high-level requirements and the detailed test cases that QA will develop.
This guide aims to help agile leaders grasp the basics of acceptance criteria, learn how to write effective ones, and understand their importance through practical examples.
Why Acceptance Criteria Matter
Acceptance criteria (conditions of satisfaction) matter for several reasons:
Clarity and Alignment: Acceptance criteria provide a clear and shared understanding of what needs to be accomplished. This clarity helps prevent misunderstandings and ensures that everyone, from the product owner to the Development Team, is on the same page. When everyone knows exactly what it looks like when a user story or backlog item is “done”, it reduces the risk of rework and helps the team deliver the right product.
Product Owner's Perspective: Acceptance criteria capture the product owner's critical needs and expectations. By defining these criteria, the product owner communicates what is essential for the user story or backlog item to be accepted. This ensures that the team focuses on delivering the most valuable features and functionalities. If these criteria are not met, the product owner will reject the story, which underscores their importance.
Guidance for QA: While the product owner provides high-level acceptance criteria, QA can expand on these to create detailed test cases. This ensures thorough testing and helps catch edge cases that the product owner might not have considered. For example, if the acceptance criterion is that a list can be sorted by any column header, QA might create test cases to verify sorting by each specific column, handling of empty columns, and behavior when the user navigates away and returns.
Prioritization: Acceptance criteria help in prioritizing work. If different criteria have different priorities, it might be better to split the story into smaller stories, each with its own set of criteria. For instance, if logging in through LinkedIn is a higher priority than logging in through Facebook or Twitter, it makes sense to create separate stories for each social network. This allows the team to focus on the most critical functionality first.
Facilitating Effective Communication: Acceptance criteria serve as a communication tool between the product owner and the team. They provide a concrete way to discuss and agree on what needs to be done. This is especially important in Agile environments where requirements can evolve, and continuous communication is key to success.
Ensuring Quality
By defining acceptance criteria, the product owner sets the quality standards for the story. These criteria help ensure that the delivered product meets the desired quality and functionality. They act as a checklist that the team can use to verify that all important aspects of the story have been addressed.
Supporting Incremental Development
Acceptance criteria support incremental development by providing a clear definition of what constitutes a done story. This helps the team deliver small, valuable increments of the product that can be reviewed and accepted by the product owner. It also facilitates continuous improvement and adaptation based on feedback.
Reducing Ambiguity
Acceptance criteria reduce ambiguity by providing specific, measurable conditions that must be met. This helps prevent scope creep and ensures that the team delivers exactly what was agreed upon. It also makes it easier to identify when a story is complete and ready for review.
Enhancing Collaboration
Acceptance criteria enhance collaboration between the product owner, Dev Team, and QA. By clearly defining what needs to be done, they encourage collaboration and discussion around how to achieve the desired outcomes. This collaborative approach helps build a shared understanding and fosters a sense of ownership and accountability within the team.
TIP: Avoiding Miscommunication: Use the term “conditions of satisfaction” can help avoid miscommunication. Product owners might associate acceptance criteria with something QA should handle, but “conditions of satisfaction” clearly indicate what the product owner needs. This helps ensure that the product owner directly communicates their expectations to the team, rather than delegating this responsibility to QA.
How to write great Acceptance Criteria?
To write good acceptance criteria, you should focus on clearly defining what needs to be true for a user story to be considered complete. Here are some tips:
1. Clarity and Precision
Acceptance criteria should be written in a way that leaves no room for misinterpretation. They should be specific and detailed enough to guide the development and testing processes. Here’s how you can achieve clarity and precision:
Use Simple Language: Avoid jargon and technical terms that might confuse stakeholders.
Be Specific: Instead of saying “The system should be fast”, specify “The system should load the dashboard within 2 seconds.”
2. Conditions of Satisfaction
Think of acceptance criteria as conditions of satisfaction. This approach helps product owners articulate what they need without getting bogged down in technical details. Here’s how to frame it:
Ask the Right Questions: Instead of asking for acceptance criteria, ask the product owner:
“What needs to be true for you to consider this story done?”
Capture High-Level Needs: Document these needs as high-level conditions that must be met.
3. High-Level Criteria
The product owner should provide high-level acceptance criteria, which are not detailed test cases but overarching conditions. Here’s how to manage this:
Focus on Outcomes: What is the desired outcome of the story? For example, “Users can successfully reset their password.”
Avoid Over-Detailing: Leave the detailed test cases to QA or the development team.
4. Avoid Over-Splitting of stories
When dealing with large stories, break them down into smaller, manageable stories. However, avoid splitting small stories into overly tiny ones. Here’s how to handle this:
Identify Natural Breakpoints: Break down large stories at logical points where functionality can be independently developed and tested.
Add Acceptance Criteria to Small Stories: For smaller stories, enrich them with acceptance criteria rather than splitting them further.
6. Team Agreement
Acceptance criteria should be agreed upon by the entire team, including the product owner, Dev Team, and Scrum Master. Here’s how to ensure this:
Collaborative Sessions: Hold sessions where the team discusses and agrees on the acceptance criteria.
Iterative Refinement: Acceptance criteria can evolve. Regularly revisit and refine them as the team gains more understanding of the requirements.
7. SMART Criteria
Acceptance criteria should also adhere to the SMART criteria:
Specific: Clearly define what is expected.
Measurable: Ensure that the criteria can be measured.
Achievable: The criteria should be realistic and attainable.
Relevant: They should be directly related to the user story.
Time-bound: If applicable, include time constraints.
8. INVEST Principle for user stories
Good user stories, and by extension their acceptance criteria, should follow the INVEST principle:
Independent: The story should be self-contained.
Negotiable: The details can be changed and negotiated.
Valuable: The story should deliver value to the end user.
Estimable: The team should be able to estimate the size of the story.
Small: The story should be small enough to be completed in a single iteration.
Testable: The story should have clear acceptance criteria that can be tested.
9. Apply the Given, When, Then structure
The essential idea is to break down writing a scenario (or test) into three sections (**):
The given part describes the state of the world before you begin the behavior you're specifying in this scenario. You can think of it as the pre-conditions to the test.
The when section is that behavior that you're specifying.
Finally the then section describes the changes you expect due to the specified behavior.
Find an example in the example section below.
By following these detailed guidelines, you can ensure that your acceptance criteria are robust, clear, and effective in guiding the development and validation of user stories. This will help your team deliver high-quality, shippable products that meet the product owner's expectations.
Examples for “good” acceptance criteria
Let’s consider a few examples that might you in writing effective acceptance criteria.
Example 1 - User Story: As a user, I am required to enter a strong password when creating my account.
Acceptance Criteria
The password must be at least 8 characters long.
It must contain at least one digit.
It must have one uppercase letter, one lowercase letter, and one symbol.
The system should display an error message if the password does not meet these criteria.
Example 2 - User Story: As a Scrum Master, I can see the results of a search for people I might want to date.
Acceptance Criteria
I can page through the results.
I can sort the results by last time on the site, compatibility, and score on the CSM test.
Results are displayed within two seconds, 95% of the time.
Example 3 - User Story: As a user, I am required to login before using the site.
Acceptance Criteria:
Proper Credentials
User is logged in only when proper credentials (username and password) are provided.
If incorrect credentials are entered, an error message is displayed.
Remember Me Option
A “remember me” checkbox is available on the login form. If the “remember me” option is selected, the user remains logged in for 30 days unless they log out manually.
Password Reminder
User can request a password reminder by clicking a “Forgot Password” link.
An email with password reset instructions is sent to the user's registered email address.
Account Lockout
User is locked out after three consecutive failed login attempts.
A message is displayed informing the user of the lockout and providing instructions to unlock the account.
Example 4 - User Story: As a user, I am required to enter a strong password when creating my account.
Acceptance Criteria:
Password Length:
Password must be at least 8 characters long.
Character Requirements:
Password must contain at least one digit (0-9).
Password must contain at least one uppercase letter (A-Z).
Password must contain at least one lowercase letter (a-z).
Password must contain at least one special character (e.g., !, @, #, $).
Feedback:
Real-time feedback is provided as the user types the password, indicating which requirements are met.
A strength meter is displayed, showing the strength of the password (e.g., weak, medium, strong).
Example 5: User story: As a customer, I want to search for products by name to find certain items easily (*)
Acceptance criteria:
The search function should return results that exactly match the entered product name.
The search function should also return results that partially match the entered product name (with at least three matching characters).
Search results should be displayed clearly and organized, including the product name, image, and price.
The search results page should allow pagination to display a maximum of 20 items per page.
Example 6: User Story: As a frequent online shopper,
I want to be able to filter products by category, price, and rating, so that I can find the most relevant items quickly.
Acceptance Criteria:
Given a user is browsing the product listing page,
When they apply a category filter (e.g., "Electronics"),
Then only products from the selected category should be displayed.Given a user has selected a price range filter (e.g., $50-$100),
When they press the "Apply Filter" button,
Then the product list should show only items within that price range.Given a user applies a rating filter (e.g., 4 stars and above),
When they view the filtered results,
Then only products with a rating of 4 stars or higher should be visible.
Conclusion
Mastering the art of writing effective acceptance criteria is a key skill for agile leaders. By understanding their purpose, following good practices, and learning from examples, you can enhance the quality of your projects and ensure successful outcomes. Embrace acceptance criteria as a powerful tool in your agile toolkit, and watch your team’s efficiency and alignment improve.
The article with written by Andreas Lehner in co-creation with ChatGPT and GoatBot
Ready to take your agile leadership to the next level?Join Agile Action Heroes, a growing community of passionate agile enthusiasts just like you. Get access to exclusive resources, expert advice, and peer support that will help you sharpen your skills and lead your teams with confidence. Whether you're looking for guidance, inspiration, or collaboration opportunities, you'll find it here.🔗 Join Agile Action Heroes Now!Resources for deep dive
https://goatbot.mountaingoatsoftware.com/
https://www.mountaingoatsoftware.com/blog/clarifying-the-relationship-between-definition-of-done-and-conditions-of-sa
https://resources.scrumalliance.org/Article/need-know-acceptance-criteria
* https://www.atlassian.com/work-management/project-management/acceptance-criteria
** https://martinfowler.com/bliki/GivenWhenThen.html