Popular Post
-
![Agilemania Blog]()
What is the Definition of Done (DOD) in S...
Apr 5th 2021 - BY Satyajit Gantayat
-
![Agilemania Blog]()
Agilemania – Gold SPCT partner of ...
Jul 26th 2022 - BY Agilemania
-
![Agilemania Blog]()
Our Scrum Master Holds the Certification ...
Jun 2nd 2020 - BY Sumeet Madan
- Agilemania
- May 25th 2022
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, its purpose, types, its format, and more — then this blog post with the real-life acceptance criteria examples and user story templates will be your guide.
What is Acceptance Criteria?
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. If you want to learn how to write good user stories, then you must read our guide to 10 tips to write great user stories – from the elements of user story to its types and characteristics, it has it all.
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.
Before you proceed further, we recommend you read the definition of done vs acceptance criteria.
User Story Template
As A “Registered User”
Please note that there are no fixed acceptance criteria templates like user story since but you will have a better understanding when you read acceptance criteria examples which we have discussed below.
Importance of Acceptance Criteria
A well-articulated acceptance criteria 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: -
- Understand expectations: Acceptance criteria are crystal clear about the task. They are testable with yes or no, pass or fail outcomes providing no scope for confusion and wrong interpretation.
- Develop a shared understanding with the client: It isn’t uncommon to see clients express dissatisfaction over the deliverables. Clients would have expected more from functionalities and clearly defined acceptance criteria will help develop a shared understanding with the client.
- Define the functionality for tests: The specified criteria will help in assessing if the system is performing according to expectations.
- Work on estimates: When the development team is clear about the requirements, the estimates will be accurate.
- Avoid Scope Creep: When an acceptance criteria is clearly articulated at the onset of a project, customers and stakeholders will not be able to change or add requirements midway through the project. Schedules and subjects won’t be subject to overrides when scope creep is taken care of.
Learn how to write good acceptance criteria: Sign Up for the PSPO Certification Training.
Characteristics of a Good Acceptance Criteria
An Acceptance Criteria is potent if it possesses the following characteristics-
- Easy to test: Since the acceptance criteria help in determining the Definition of Done, the acceptance criteria should be easy to test. The results should not be ambiguous. The test should declare Yes/No or Pass/Fail results.
- Simple and succinct: The acceptance should not be comprehensive. It should be simple and to the point.
- Understandable: Your acceptance criteria serve no value if the developers are not able to understand the same. Discuss with them and modify them until everything is clear.
- Provide user perspective: Acceptance criteria should describe a problem from the perspective of users. It should depict the real-life user experience.
Acceptance Criteria Examples
Acceptance 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-
- Given some precondition
- When I take some action
- Then I anticipate a favorable outcome
- Scenario – the name for the behavior that will be detailed
- Given – the start status of the scenario
- When – specific action taken by the user
- Then – the result of the action in “When”
- And – used to continue any of above three statements
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-
- The developers don’t require a detailed test scenarios
- Software design needs to be elaborated
- The user stories detail a system functionality level requiring a unique QA approach
- The search field is located on the top right bar.
- Search starts when the user clicks “Search.”
- The search field contains a placeholder with gray-colored text, “What are you looking for?”
Who is Responsible for Writing Acceptance Criteria?
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-users 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.
When Should You Write Acceptance Criteria?
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.
You might be interested in reading: Definition of Done vs Acceptance Criteria
Limitations of Writing Acceptance Criteria
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-
- Extremely Narrow: Acceptance criteria is written for a specific use case, scenario, or technical case. Because a solution is already devised when writing acceptance criteria, there’s a high chance of leading the developers in a different direction. A pitfall of being narrow is that the testing might overlook user behaviours not specified in the acceptance criteria. As a result, poor testing equals higher chances of failure.
- Unnecessarily Broad: A common criticism of acceptance criteria is that it is unnecessarily broad. When the acceptance criteria is too detailed, the user story may get lost in communication. An effective acceptance criteria should prescribe a limit so that developers can code for what is required and nothing less or more.
- Complicated: Acceptance Criteria becomes complicated when there is too much jargon and technical terms involved. Acceptance criteria should be written in plain and simple language so everyone understands them.
Best Practices
Exceptional Acceptance Criteria aren’t hard to write. Here are seven best practices to help you write an acceptance criteria that is valuable-
1. 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.
2. 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 criteria increases the chances of leaving out user actions that might be significant.
3. 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.
4. 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.
5. 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.
6. 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.
Key Takeaways
As we conclude the blog post, here are the key takeaways-
- Acceptance Criteria is the set of predefined conditions that must be fulfilled to ensure that the product fulfills end-users expectations.
- Acceptance Criteria should be easy to test, understandable, simple, and convey user perspective.
- The Acceptance Criteria should preferably be written before the beginning of the development session and not after it starts.
Find Our Upcoming Training
Agilemania
Agilemania, 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.
Sign up for Agilemania Newsletter
Stay updated with the latest Agile & Scrum trends.
Popular Post
-
![Agilemania Blog]()
What is the Definition of Done (DOD) in S...
Apr 5th 2021 - BY Satyajit Gantayat
-
![Agilemania Blog]()
Agilemania – Gold SPCT partner of ...
Jul 26th 2022 - BY Agilemania
-
![Agilemania Blog]()
Our Scrum Master Holds the Certification ...
Jun 2nd 2020 - BY Sumeet Madan
Agilemania is a group of passionate Lean-Agile-DevOps consultants and trainers focused on delivering measurable, sustainable results for our clients.
Connect with us on Social Media
Knowledge Area
Certified Partners
Agilemania Technologies Private Limited © 2024 All rights reserved.
