When is a task considered done? When the task meets its requirements. However, requirements can be deliberately vague or written from a high level. While requirements tell us what the overall product should do, they don’t define all the standards it should meet.
That is the job of another agile project management artifact called acceptance criteria. In this blog post, we explore what acceptance criteria are, why you need it, and how to write acceptance criteria for your project.
- What Are Acceptance Criteria?
- Characteristics of Effective Acceptance Criteria
- Why do Acceptance Criteria Matter?
- How to Write Acceptance Criteria
- Common Mistakes to Avoid While Writing Acceptance Criteria
- Best Practices for Writing Acceptance Criteria
- Examples of Acceptance Criteria
- The Role of Acceptance Criteria in Agile Methodologies
What Are Acceptance Criteria?
Originating in software engineering, acceptance criteria are a set of conditions that a new feature/increment must meet to be considered complete.
In literal terms, these are the criteria based on which a feature would be accepted by the product owner or customer.
Characteristics of Effective Acceptance Criteria
Acceptance criteria are the last checkpoint for whether the product/feature is ready for the user. They are the stamp of approval that the product/feature is good enough for production.
To be effective, acceptance criteria must be:
User-focused: Teams create acceptance criteria from the perspective of the user to ensure alignment with business objectives.
Outcome-driven: Unlike a user story, acceptance criteria define the desired outcome. Therefore, they also need to be measurable.
Specific: Each criterion needs to be specific and applicable to one aspect of the feature.
For example, ‘must be compliant for OWASP top ten vulnerabilities,’ can be an effective criterion as it is specific to security alone.
Concise: They must be short sentences. They must use language and nomenclature that the dev team uses and is comfortable with.
Independent: It is good to ensure that one acceptance criterion doesn’t depend on another, creating a web of complexities.
Testable: This is the most important aspect. A good acceptance criterion needs to be testable. Typically, in the form of yes or no outcomes.
Why do Acceptance Criteria Matter?
Every software team knows how to gather requirements in agile to define exactly what the product owner/customer needs. Why, then, do we need another artifact, you ask? Here’s why.
Common context
Acceptance criteria create a common understanding among product owners, developers, and quality analysts about each feature. They avoid confusion, subjective interpretation, and potential misunderstandings.
Product alignment
Acceptance criteria serve as the scale that measures the product/feature’s alignment with the requirements, goals, and objectives. They connect the code back to the business.
Testing efficiency
When you have clearly defined acceptance criteria, your quality teams can automate and accelerate the agile testing process. They also create repeatability across sprints.
Project management efficiency
Good acceptance criteria enable better monitoring, tracking, and project control measures. It gives clear visibility into why a feature has gone back to rework, helping project managers optimize processes.
Positive closure
At its core, acceptance criteria outline the definition of done in agile projects. So, when all the acceptance criteria are met, you can confidently ship a product knowing you’ve done everything needed.
If that has convinced you to incorporate acceptance criteria into your projects, here’s how to get started.
How to Write Acceptance Criteria
Tempting as it might be, writing acceptance criteria isn’t a one-person job. To be effective, the acceptance criteria must incorporate various stakeholders’ inputs. The product owner typically writes acceptance criteria with technical input from the development team.
Below is a strategic and comprehensive approach to writing acceptance criteria collaboratively with the help of an all-in-one product management tool like ClickUp.
1. Understand the purpose of acceptance criteria
The first step is to explore why you’re writing acceptance criteria. Is it only for the QAs to run tests? Is it outlined by the customer? Are these compliance requirements? Is this a proof of concept? Understand the purpose of the acceptance criteria to ensure that it’s effective for that audience and need.
While the actual acceptance criteria will be crisp and testable, the document of purpose will explore the why in detail. For example, let’s say, one of the acceptance criteria is “enable contrast scheme for low vision.”
The document of purpose might say, “low vision features are fundamental to our app as we serve customers over 50 years of age. A product that is easy to use for this audience will dramatically reduce the burden of home visits for our on-ground team.”
ClickUp Docs is a great place to bring all the information together and define your purpose. Use this as a read-me to get every stakeholder on the same page (literally!) about the need and importance of acceptance criteria.
Collaborate in real time, making edits, leaving comments, and tagging people for feedback. When done, you can also create tasks right from within your ClickUp Docs.
Bonus: A primer on epics vs. features to help you write your user stories.
2. Start with user stories
Now that your context is set, it’s time to get writing. Begin with the user story. Look through the user journey that each feature must enable and write corresponding acceptance criteria.
While using ClickUp Tasks for your user stories, you can create custom fields for specific details like the user’s role, goal, desired outcome, dependencies, etc. With all that information in one place, think about what ‘done’ should look like.
If you’re entirely new to this, here’s a beginner-friendly template to get you started. Use ClickUp’s User Story Template to manage stories, break them into tasks, prioritize features, develop them, and ship world-class products.
3. Write the acceptance criteria
Based on the user story, write the acceptance criteria. The simplest way to do this is as a checklist. For example, when you’re building a single-field form for newsletter subscriptions, your acceptance criteria list might look like:
- User should be able to enter their email address
- The system should send a confirmation email to the provided and validated email address
ClickUp Task Checklists can handle all this right within the task you’ve created for the user story. Under each task, add checklists for the acceptance criteria applicable to it.
Do you have common security or performance criteria applicable to all tasks? No sweat! Create a checklist template and apply it automatically to all relevant tasks.
4. Use the Given-When-Then format
Another way to define acceptance criteria is by using the Given-When-Then (GWT) format. Simply put, here’s what it looks like.
- Given: Initial state or context of the software
- When: Action or event that the user undertakes
- Then: Expected result
Essentially, this translates to given a <certain scenario>, when the intended user performs a <certain action>, then the <expected result> should happen. Let’s see that as an example.
When you’re building the same newsletter subscription feature,
- Given: User is trying to sign up for the newsletter
- When: User enters their valid official email address
- Then: An automated email is sent confirming their subscription
5. Collaborate with stakeholders
Good acceptance criteria aren’t written in a silo. Typically, product managers bring the perspective of the user and business needs. The design team would focus on user experience, usability, accessibility, etc. The development team contributes to the technical specifications. DevOps would care about performance and resource utilization.
To ensure that your product meets all these requirements, you need to write the acceptance criteria collaboratively. With ClickUp, that can be deceptively simple.
For every user story’s task, add the acceptance criteria, either as a checklist, a custom field, a description, or a comment. Use ClickUp’s nested comments to discuss each acceptance criterion and @mention for stakeholder communication. Assign action items and more.
6. Keep it simple and concise
Try not to use conjunctions in your acceptance criteria. No ‘and’ or ‘or.’ Keep it short, preferably one simple sentence. Use the words ‘should’ and ‘must’ instead of ‘can,’ ‘may,’ or ‘might.’
7. Ensure testability
To ensure that your acceptance criteria are met, you need to test them. The way you write the criterion plays a critical role in that. Make sure that your acceptance criterion lends itself to writing test cases. Let’s extend the previous example.
If the acceptance criterion is ‘user should be able to enter their email address,’ then the test case would be:
Steps:
- Type email address
- Press enter
Result:
- If no, display message, “Please enter your official email address”
- Validate email address as official
- If yes, display message, “Thank you for your subscription. We’ve sent you a confirmation email”
8. Review and revise
Throughout the development process, monitor and optimize your acceptance criteria. With ClickUp, you can also set up reports for each of them to see what needs your attention.
Use ClickUp Dashboards to create customizable widgets for the acceptance criteria that matter to you. See which features are lagging behind and develop strategies to address the root cause.
With that, you’ve learned what to do. Now, let’s turn our attention to what not to do.
Common Mistakes to Avoid While Writing Acceptance Criteria
Across technical, functional, and operational parameters, you can make any number of mistakes while writing acceptance criteria. Here are the common mistakes that teams generally make.
Doing it alone
Product owners often feel the pressure to write the acceptance criteria on their own. Even if well-intended, this approach can miss out on the technical expertise of the development team.
Always write the acceptance criteria collaboratively.
Ignoring the user
As acceptance criteria are at the far end of the development process, it is easy to forget about user experience. This is a grave mistake.
Always create your acceptance criteria around the end-user.
Focusing on how
Acceptance criteria aren’t about how a software tool should work. They are about what results it should produce. Writing acceptance criteria that define ‘how’ to write the feature can turn counterproductive.
Always focus on expected results and outcomes.
Keeping it vague
Vague or broad acceptance criteria do the opposite of what they’re meant to: They leave it open for interpretation. This means that the outcome might vary based on the tester, circumstances, or even the environment.
Always make the acceptance criteria clear, specific, and unambiguous.
Adding too many
While there is no scale for what’s a reasonable number, it is a huge mistake to write too many. In fact, having too many acceptance criteria might indicate that you need to break down the user story itself into further smaller parts. Look at the agile story points on the user story to confirm this theory.
Always list only the absolutely necessary acceptance criteria.
Best Practices for Writing Acceptance Criteria
Acceptance criteria are an important collaborative communication tool for software development teams. In this section, we’ll focus on how you can make it as effective as possible.
Be clear
Make the acceptance criteria clear to every stakeholder. The developer needs to understand what the acceptance criteria mean. And the quality analyst needs to know how to convert that into a test case.
Use simple language
Write your acceptance criteria in plain English. Don’t use technical language. Especially do not veer into telling the developer how the code must be written.
Keep the results binary
An acceptance criterion is either met or not. There is no partially met or 80% complete. So, write acceptance criteria as pass or fail statements.
Make it measurable
The simplest way to achieve pass-or-fail outcomes is by making them measurable. For instance, if your acceptance criterion is “less than 3 seconds page-load speed,” it is easy to test and pass.
Make reasonable assumptions only
Often, product owners might think of something as ‘obvious,’ given how close they are to the user. It might not be as obvious to the developer. So, don’t make assumptions at all, if you can avoid it. When you need to, make reasonable assumptions in collaboration with the team.
Examples of Acceptance Criteria
Let’s explore some acceptance criteria examples in the real world, not just in software development, but across other functions too.
Example 1: Software development (using checklist method)
Task: Search functionality on a content-driven website.
Acceptance criteria:
- There should be a text box for users to type in their search query
- Results should be displayed as a list
- Results should open on a new page
- Results should be paginated
Example 2: Software development (using GTW method)
Task: Appointment booking feature
Acceptance criteria:
- Given that an existing customer wants to book an appointment
- They enter their email ID and choose preferred appointment slot
- Their appointment should be booked and confirmed via email
Example 3: Content writing (using checklist method)
Task: Write a 1000-word blog post about the latest Tom Cruise movie
Acceptance criteria:
- Use US English
- Use Oxford Comma
- Keep the introduction to less than 200 words
- Include 3-5 internal links
Example 4: Marketing (using GTW) method
Task: Run an intent-based ad campaign on Google Search
Acceptance criteria:
- Given user is on any of Google search interfaces
- When user types a keyword in our list of <intent keywords>
- Then display <particular ad>
The Role of Acceptance Criteria in Agile Methodologies
If agile is about breaking monoliths into small, manageable parts and building them incrementally, acceptance criteria accentuate it.
For example, you might break down your big e-commerce platform into small parts, one of which is the add-to-cart feature.
Within add-to-cart, there might be multiple little functionalities, like what if the product is out of stock or how the user can adjust the quantity to be added to the cart. Well-written acceptance criteria help zoom into these granular details.
Within agile methodologies, acceptance criteria help in:
Defining outcomes: Acceptance criteria tell the quality team what a completed feature looks like.
Facilitating discussions: Agile development isn’t just about code. It is about solving business problems with tech. Acceptance criteria help facilitate these discussions to enable the right trade-offs and related decisions.
Bringing cross-functional teams: Product owners, business analysts, designers, developers, testers, and ops teams all gain a common understanding of the product based on the acceptance criteria.
Enabling progress: Once acceptance criteria are met, the task moves to the next stage in the software development life cycle.
Ship Better Products Faster with ClickUp
One of the key steps in building good software is to meet the stated acceptance criteria. However, between the dozens of documents, reports, meetings, planning, and discussions, it is common for some items to fall through the cracks. Avoid that with a product management tool like ClickUp.
ClickUp isn’t just a task manager. It is a comprehensive platform designed with product development teams in mind. With the powerful ClickUp Tasks, plan and schedule user stories, add acceptance criteria, link them to test cases, and move them down the pipeline quickly and effectively.
Ship faster with ClickUp Brain to generate ideas, create roadmaps, summarize discussions, and build documentation. Monitor the big picture and the granular details all in one place with ClickUp Dashboards. See if ClickUp meets your acceptance criteria for a great product management solution.