
Agilemania
Agilemania, a small group of passionate Lean-Agile-DevOps consultants and trainers, is the most tru... Read more
Have You Registered for Our PMP Training Worth ₹14,999—Absolutely FREE?
Scrum.Org
SAFe®
ICAgile
Scrum Alliance
Technical Agility
Kanban
Business Analysis
Project Management
AI-Powered
Scrum.Org
SAFe®
ICAgile
Scrum Alliance
Technical Agility
Kanban
Business Analysis
Project Management
AI-Powered
Agilemania
Agilemania, a small group of passionate Lean-Agile-DevOps consultants and trainers, is the most tru... Read more
If there’s a topic that has been discussed in online forums since time immemorial, it has to be Acceptance Criteria. While there is a lot of buzz around the term, a lot of organizations face trouble when writing the acceptance criteria. This throws the development team off balance.
The result? Shoddy product increments. If you’re looking to learn about acceptance criteria, their purpose, types, format, and more — then this blog post with real-life acceptance criteria examples and user story templates will be your guide.
Acceptance Criteria is the set of predefined conditions that must be fulfilled to ensure that the user story is complete. So, what is the user story? In the simplest terms, a User Story is a way of expressing requirements from the perspective of the user of the product or system, or software.
A User Story follows 3C’s – Card, Conversation, and Confirmation. In addition, it is often helpful to have six attributes defined by the acronym INVEST – Independent, Negotiable, Valuable, Estimable, Small, and Testable, to be part of a user story.
We know that by just learning what the acceptance criteria and user story is, it won’t be enough until you learn the importance of writing it and how to write one. Let’s learn with good acceptance criteria examples to have better clarity.
As A “Registered User”
I WANT TO “Search for books by author’s name”
SO THAT “I can find and buy books by my favorite author”
Here are some examples of well-written acceptance criteria:
User Story: As a user, I want to be able to reset my password so that I can regain access to my account if I forget it.
Acceptance Criteria:
Given the user is on the login page,
When they click on the "Forgot Password" link,
Then they should be directed to the password reset page.
Given the user enters their registered email address,
When they click the "Submit" button,
Then a password reset link should be sent to their email.
User Story: As an admin, I want to be able to view user activity logs so that I can monitor user behavior on the platform.
Acceptance Criteria:
Given the admin is logged into the admin dashboard,
When they navigate to the "User Activity" section,
Then they should see a list of user activities in chronological order.
Given the admin selects a specific user,
When they click on the "View Details" button,
Then they should see a detailed log of the user's activities.
A well-articulated acceptance criterion removes ambiguity about the functionality to be built. The development team will be clear about the client requirements and what the final deliverable should look like. Writing acceptance criteria helps us to: -
We won’t let you wonder if you have written the acceptance criteria correctly or not, therefore, we will show you what a good acceptance criteria looks like.
An Acceptance Criterion is potent if it possesses the following characteristics-
As promised, we will provide you with acceptance criteria templates to help you write the best one.
Think of acceptance criteria as a simple checklist that keeps everyone on the same page. They ensure the final work meets expectations and avoids last-minute surprises.
Below, we’ll walk through the main ways acceptance criteria are used and why they matter.
1. Clarity and Alignment: Acceptance criteria make sure that all participants have a shared grasp of what the final product should be and how it should perform. This ensures there is no confusion and therefore allows for minimized miscommunication in future programming.
2. Measurable Success: By establishing specific and concrete barometers, the amount of development required to fulfill that task or feature is made meaningful. This barometer establishes efficient testing and keeps the project moving along correctly.
3. Communication and Collaboration: Acceptance criteria serve as a communal bridge across constituencies: developers, product owners, and testers. The framework will clear any impediments in communication and collaboration during the developing lifecycle.
Empower your team! Become a Scrum Master and facilitate the process by identifying potential ambiguities in criteria, clarifying their purpose, and encouraging developers to voice concerns about unclear criteria.
Become a Scrum MasterAcceptance Criteria can be written in two formats-
1. Scenario-oriented acceptance criteria (Given/When/Then): Scenario-oriented acceptance criteria is a type that describes the same in the form of a scenario. It follows the Given/When/Then) approach which is as follows-
This approach is borrowed from Behavior Driven-Development (BDD) where testers are provided with a concrete structure that prescribes when to start and end testing a particular functionality. It also minimizes the time that is spent on writing the test cases.
Acceptance Criteria example (scenario-oriented):
“As a website user, I want to be able to search on the webpage So that I can find necessary information.”
Scenario: User searches for an item by its name
Given that I’m in the role of a registered or guest user
When I open the “Products” page
Then the system shows me the list of all products
And the system shows the “Search” section in the right top corner of the screen
When I fill in the “Search” field with the name of an existing item in the product list
And I click the “Apply” button OR press the Enter key on the keyboard
Then the system shows products in the Search Results section with product names matching entered product name
And the system shows the number of search results at the top of the Search Results section”
2. Rule-oriented Acceptance Criteria: The Rule oriented acceptance criteria contain a set of rules that narrate the behavior of a system. This type of acceptance criteria is suitable when-
Acceptance Criteria example (rule-oriented): As a user, I want to use a search field to type a brand, size, or cost, so that I could find results for matching shoes
We are quite sure that now you are at a better place than before with our acceptance criteria examples. If you want to learn the best practices of writing acceptance criteria, make sure you stick with us until the end.
The Product Owner is responsible for writing the acceptance criteria with the entire cross-functional team chipping with their contributions. The acceptance criteria should be written from the end-user's perspective. The development team should be involved since they will be able to define acceptance criteria addressing the customers' needs.
Involving the development team can help the Product Owner communicate the product vision and roadmap to them. Second, it helps the developers identify dependencies that might have slipped from the radar. Now that you know that the product owner is responsible for writing acceptance criteria, it is also important when they should write one.
While there is no hard and fast rule as to when the acceptance criteria should be written, it is ideal to write it before the development starts. A common practice used by product owners and product managers is to write the acceptance criteria during backlog refinement events.
This is later discussed in the sprint planning meeting with the development team and modified as per their feedback. One mistake that teams should avoid committing is writing the acceptance criteria way early. Since reprioritizing is an agile practice, you reprioritize user stories from sprint to sprint.
While Acceptance Criteria has a fair share of benefits, there are a few limitations that weaken its stance. Here are a few common downsides of acceptance criteria-
Now that we are well aware of what acceptance criteria are, what their importance is, their types, and so much more — it’s time to learn the best practices for writing acceptance criteria.
Take advantage of our Scrum Master assessment designed to help you score high and advance in your career. Gain valuable insights and skills necessary to succeed in the role.
Take the test!Document your criteria before development begins: Acceptance criteria serve no purpose if it's created after, during, and towards the end of the development process. It must be documented early before the development process starts. This clean practice helps the development team understand the customer requirements so they can later plan the development.
Avoid making it narrow: In your attempt to make the acceptance criteria as crystal clear, the outcome is too specific. This leaves the developers confused. The acceptance criteria should convey intent and the ultimate solution. A narrow criterion increases the chances of leaving out user actions that might be significant.
Achievable: Stuffing your acceptance criteria with too many functionalities will leave the developers working on too many tasks at once. Keep it simple, so the development team can work on what’s important.
Make it actionable: Being too broad renders the acceptance criteria useless. It should just outline the task for the developers to understand the user requirements and start working on it. Include just the details needed for the developers to take action.
Ditch technical for simplicity: Jargon and technical terms won’t help the development team. The acceptance criteria should be written in plain and simple language so all the non-technical stakeholders can understand them easily.
Shared understanding: The acceptance criteria should be able to communicate the user requirements to the stakeholders and the development team. There should be a shared understanding as to what tasks are a priority and what isn’t. With that, we have reached the end of this blog. But surely, we won’t end it without having a quick overview of what we have learned so far.
While acceptance criteria are a powerful tool, there are common pitfalls to watch out for:
Being Too Vague: Vague acceptance criteria lead to misunderstandings and incomplete features. Be as specific as possible to avoid ambiguity.
Overcomplicating Criteria: While it’s important to be specific, avoid making acceptance criteria too complex. They should be clear and concise, focusing on the key aspects of the feature.
Ignoring the User Perspective: Acceptance criteria should always be written from the user's perspective. Failing to do so can result in a feature that doesn’t meet the user's needs.
Not Updating Criteria: As requirements change, it’s crucial to update the acceptance criteria accordingly. Outdated criteria can lead to features that are no longer relevant or useful.
Skipping Edge Cases: Ignoring edge cases can lead to issues down the line. Always consider and document potential edge cases in your acceptance criteria.
As we conclude the blog post, here are the key takeaways-
So, what were your learnings? If you need help with writing captivating acceptance criteria, then we’re right here to help.
Explore our continuous learning opportunities crafted by our coaches and trainers to empower your agile journey. Contact us today to discover the next best step for your career.
Scrum Master Learning PathAgilemania, a small group of passionate Lean-Agile-DevOps consultants and trainers, is the most trusted brand for digital transformations in South and South-East Asia.
WhatsApp UsWe will get back to you soon!
For a detailed enquiry, please write to us at connect@agilemania.com