Our official whiteboard for blog posts, musings, and occasional swashbuckling.
Senior Technology Writer
I’m a former science journalist that likes to connect the dots between science and technology.
👍 Rating — 5 (3 votes)
To succeed in software development, we must first ensure that the dev team is all moving in the right direction. As a project manager, you may even feel that you’re running “one step behind,” which is why Acceptance Criteria is so important. The Project Management Institute’s Pulse of the Profession reports that for organizations with high project management maturity, 27% of their projects did not meet original goals and business intent.
So what is it? Acceptance Criteria is how you define your software development goals so you can reach them most efficiently.
Writing and using Acceptance Criteria provides the firm foundation upon which a team can build great software. As such, we’ll provide some project acceptance criteria examples so that you can get an idea of how to implement them within your own team.
At its most basic level, Acceptance Criteria is how you determine whether an existing code change will fix any problems—or create more issues. That’s why sometimes Acceptance Criteria is also referred to as the ‘must-pass’ criteria. The idea is that such criteria help prevent developers from turning in broken code.
Great. Awesome. Right? And yet, here’s the plot twist: there are no templates for Acceptance Criteria.
You will not find an exhaustive list of requirements that should be covered by Acceptance Criteria associated with any particular user story.
Every product is different, so it really depends on your needs and the specs to be built.
For instance, your desired functionality, expected performance, constraints, and restrictions may all be described in your product team’s Acceptance Criteria. They can include components like:
In other words, you first have to understand the complexity of a particular function before the minimum set of actions to develop a new function properly is determined by the team.
That’s why it’s essential to have a clear set of Acceptance Criteria for any new feature being created—it eliminates confusion and setbacks and makes sure everyone is on the same page.
Acceptance criteria may be written in different formats, including bullet points, tables, or scenarios. There is only one requirement, as mentioned previously: Acceptance Criteria must clearly show what should be in place to make the system work as intended.
Definition of Done is a crucial process every Agile team needs to follow since it lays out the technical criteria for when a new product or feature is deemed ready for release. It ensures that all user stories are completed in a high-quality manner and helps keep a good return on investment for any software development project. Or said another way, it is really a code stack type of checklist.
Acceptance Criteria, by contrast, are the overall requirements for the new feature or functionality. For example, does it allow the user to access the new feature easily? Does it work as intended? Does it provide the performance that users had been asking for?
These Acceptance Criteria are individually set for each story.
In sum, any good software development project or process usually clearly distinguishes between Acceptance Criteria and the Definition of Done. It’s also essential to articulate the two in terms of the metrics that are used and communicated to the team.
Even though requirements for a new feature or function are often murky at the start, software development teams should always strive to create a robust Acceptance Criteria document, as even the most minor pieces prove critical down the road.
To get the best outcome for a given criteria, it must be defined and communicated in such a way as to capture the requirement in full. Even if the requirement is done with the customer – or reflects a persona or end-user—there is no guarantee that the work will come out the other side as initially visualized.
And criteria should always be couched in a strong understanding of the end-user context—in other words, why the client or customer needs the software or feature.
This point analysis will help the development team internalize user needs and increase the chances that the software or app will be successful.
To be fair, implementing Acceptance Criteria does not mean a new feature will be perfect out of the gate. The development could still potentially result in costly rework or iterations of the project at hand and, ultimately, the dreaded scope creep.
But Acceptance Criteria can help ensure that your projects have the highest probability of success.
Outside of understanding user needs, here are other reasons why a project manager or a product owner has to create Acceptance Criteria:
Need Acceptance Criteria but don’t have anyone on staff who is ready to implement? Delegate this part of planning to someone else. We're ready to help!
Three types of Acceptance Criteria are commonly used. The following provides a description of each, along with some examples for your perusal.
Here is a template of the scenario-oriented approach to Acceptance Criteria known as the GWT (Given, When, Then) formula:
This method has been borrowed from behavior-driven development.
GWT is most commonly used at the beginning and the end of testing a particular feature and is helpful for automation QA engineers doing unit tests.
Let’s say we have a user story that describes the ‘Contact Us’ feature on the TurnKey blog post page:
According to the Given/When/Then template, the Acceptance Criteria would be the following:
Scenario: User presses a Call to Action button to contact TurnKey
“Given that I’m in the role of guest user
When I open any blog post page
Then the system shows me the blog post
And the system shows several “Call Us” sections in every blog post
When I hover the mouse pointer over the CTA button
And I click it
Then the system shows the contact form with the TurnKey contact details
And the system shows a contact form I can fill in and submit to be contacted”
In some cases, GWT is useless. For instance:
The rule-oriented approach to Acceptance Criteria usually consists of rules describing the product’s behavior.
Based on the rules, you create specific situations.
Here is a template of the rule-oriented approach to the Acceptance Criteria:
Here is how we would describe the ‘Contact Us’ feature on the TurnKey website’s main page using the rule-oriented approach:
Sometimes neither of these methods works for a product backlog, and in those cases, it may require creating a custom format for Acceptance Criteria.
It’s up to you to determine what your Acceptance Criteria look like. It may be anything that works for your team and your customers.
Too confusing—but essential at the same time? We get it. And we got you. TurnKey is ready to get you set up with what you need.
When defining their projects’ acceptance criteria, software development teams should follow these best practices.
By anticipating all the user needs, the team is more likely to meet them.
Before the team starts the development process, you must establish the product vision for a couple of sprints. To do that, you document the development requirements and use them in the planning process.
If the Acceptance Criteria are too specific, they leave developers few chances for flexibility. To avoid this, you need to have an Acceptance Criteria which states the intent of your system, not a final decision.
Fine line, right? When Acceptance Criteria are too-broad, user stories are vague. They should be very precise.
User Acceptance Criteria should specify the scope of work so developers know how much work they must do to create a working product version.
Well-defined Acceptance Criteria help determine what you have to do to complete a particular task or achieve a goal, and they help you ensure you deliver that functionality.
If you describe all the small specifics about what you’re doing, your team may get stuck on hundreds of tiny details.
Acceptance criteria should be written in plain English.
Your stakeholders and managers don’t need to understand programming. So writing it plainly will help everyone get the criteria across.
Also, include examples to help everyone understand how the criteria apply.
Different people can solve the same problem differently.
Ensure you communicate your Acceptance Criteria to stakeholders and team members and reach a mutual agreement.
This allows testers to ensure that all requirements are met and allows developers to know if the user story is complete.
Don’t use the word “not” when writing a requirement because it’s difficult to verify or validate that the requirement was met.
Be strong in your wording and convey the user perspective. If no one is responsible for executing the action, it will be unclear who or what must take it, and you’ll have a hard time verifying whether the requirement has been fulfilled.
TurnKey has a scalable and repeatable engine for new technology creation and provides the tech expertise needed to stand up and optimize the performance of your software development teams, whether big or small.
Our Managed Services division can lead all roadmap and sprint planning and can take responsibility for making sure all deliverables and timelines are met. TurnKey also measures and reports all the KPIs, so you can be sure that the software development progress goes smoothly and drives real results for your customers.
Want to make the software development process in your company super efficient? We're ready to help.
Acceptance Criteria should be easy to understand and describe the key functionality that a new feature or product should deliver. It should also be measurable by your organization's existing system or processes.
Acceptance Criteria is expressed in terms of specifications or conditions that must be met by the product before it can be accepted as “Fit for use.”
Acceptance Criteria is a set of requirements, usually expressed in the form of questions, which define the acceptance of a deliverable. There may be more than one Acceptance Criterion for a deliverable. However, the deliverables must satisfy all of the acceptance criteria to be considered ready to launch.
Acceptance Criteria are written as phrases describing what is to be achieved or what is not to be achieved. Each phrase describes one characteristic of the requirement that should be met. Keep it in plain wording as this is meant to be shared with a broad group, not just highly technical developers.
Requirements are the technical conditions that must be met before a system, product, or service can be considered complete. Acceptance criteria are used to evaluate a solution based on whether it meets its broader functional or user experience requirements (ie “does it allow a user to reset their password?” etc.).
Tailor made solutions built around your needs
Get handpicked, hyper talented developers that are always a perfect fit.
Here are recent articles about other exciting tech topics!
Pros and Cons of Offshoring: Which One Is The All-Pro Choice?
How to Hire a CTO: An In-Depth Guide for Success
Overview of The Latin America Software Industry
Extended Development Team: How To Use It To Supercharge Your Software Development