What you need to know about acceptance criteria

The current wave of AI has everyone on the edge of their seats. The software industry continues to evolve at blistering speeds, often on the order of weeks. Prior, it used to be on the order of years. One of the major shifts in software development is that it isn’t just restricted to the technically gifted (read: developers) any longer. Non-technical folks have entered the game and are vibe-coding their way through workflows. Platforms like n8n and make.com are making development more modular and visual. This is one of the drivers for why we are seeing such tremendous growth, with the software industry set to reach $125.45 billion by 2030, registering an annual growth of 20.3%.

With more low-code or no-code tools being introduced to the market, software development will continue to become more accessible to regular people. However, with this acceleration comes a critical challenge: unclear or changing requirements. As more people build software, defining what “done” looks like becomes even more crucial.

Charles R Martin, former staff engineer at Sun Microsystems, puts it bluntly: “Requirements change. Every software engineering project will face this hard problem at some point.”

This is where acceptance criteria comes into the picture, a simple yet powerful tool to combat ambiguity and align teams, ensuring that the resulting software meets real needs as per expectations.

In this post, we’ll explore topics such as: What is acceptance criteria? What is an example of acceptance criteria? Why is it important? And what are some best practices for writing effective acceptance criteria?

In software engineering, acceptance criteria is the set of requirements that a user story must fulfill in order to be deemed as done or complete by a product or service’s stakeholders.

What is acceptance criteria?

In software engineering, acceptance criteria is the set of requirements that a user story must fulfill in order to be deemed as done or complete by a product or service’s stakeholders.

Let’s understand this via an example. For instance, a warehouse operator might request a dashboard that displays all the trucks that checked in and checked out from a warehouse in the past 24 hours.

However, if you think about it, this level of detail on its own might be insufficient. Put yourself in the developer’s shoes: How many users should the dashboard be able to manage? What should it look like? At what frequency should the data be updated? We’ll need more granular “acceptance criteria.”

While answering these questions, the finer details may then turn out to include:

• Dashboard should be able to handle 15 concurrent users
• Each user should have a view specific to the persona, and a mock-up of the specific view should be provided
• The dashboard should be password-protected
• The dashboard’s data should be refreshed every hour

Importance of acceptance criteria in software development

Any experienced software developer would vouch for wanting to have documented acceptance criteria, as it brings a number of benefits.

Helps avoid rework

When acceptance criteria aren’t well documented and aligned, each person on the team will tend to have a slightly different understanding of the requirement. For example, “design a futuristic button” could mean having a minimalistic white button to one person and a neon blue square button to another. When the acceptance criteria is clearly called out and defined, days, weeks, and even months of rework can be avoided.

Avoids scope creep

Let’s face it. Business stakeholders rarely understand the complexity of redesigning a whole algorithm. More often than not, the “small change” requires refactoring code that has trickle-down and trickle-up effects on both downstreams and upstreams. Many times, it requires major fixes at both the code and UI levels. Having the acceptance criteria laid out helps ensure that the scope of work remains constant and that any new request is handled via appropriate change management.

Generates better estimations

Having a better idea of the acceptance criteria means that developers can provide better estimations for their sprints. This helps with more reliable and accurate planning. Project sponsors, product owners, and developers are in a better position to discuss trade-offs and are able to distinguish between the must-haves and nice-to-haves in the development cycle.

The acceptance criteria is drafted when requirements are being captured as part of the product backlog.

How acceptance criteria fit into development and testing?

Some readers might wonder: How does acceptance criteria impact the testing and quality assurance process?

The acceptance criteria is drafted when requirements are being captured as part of the product backlog. As discussed earlier, developers will use acceptance criteria as a standard to build the functionality. QA/testers will rely on it to draft test cases and execute testing. Subsequently, stakeholders/sponsors will use it to verify/validate the work in order to deem it “done.”

Acceptance criteria vs. user stories

You might be wondering: How do acceptance criteria differ from user stories? Both terms are important and related concepts in software development.

User stories outline the functionality of a feature from a user’s perspective. Typically, the user story follows a format like “As a [persona], I should be able to do [action], so that I can [benefit].” For example, as a marketing analyst, I should be able to filter all the prospects collected in the past 24 hours, so that I can email everyone in one click.

On the other hand, acceptance criteria define the conditions that must be met in order to fulfill the backlog item. Continuing our example above, the prospects should:

• Be savable and exportable into an Excel sheet
• Have the following columns: name, email, contact number, website
• Only be from North America
• Automatically flow to a Gmail draft, ready to be sent

Holistically speaking, the user story guides the who, what, and why of the functionality. Acceptance criteria establishes the how of the functionality.

Who should write the acceptance criteria?

Collaborative effort between the business, product owner, and developers is key while drafting user stories. Hence, acceptance criteria writing, too, is a joint effort. The final say, however, comes from the product owner or business analyst.

Suppose you have this user story: As a YouTuber, I want to mass upload my videos to YouTube to save time. Here, the business requirement is clear. However, the developers will be able to give insights on the different architectural frameworks that can be used and the trade-offs between them. The business requirements will come from the business/sponsors, meanwhile, the technical criteria are drafted and influenced by the developers.

How to write effective acceptance criteria?

The exact process can vary across teams, but the general dynamic remains the same. Here are a few steps outlining the process.

The better we understand the business objective and the overall goal of the story, the better job we do at creating the acceptance criteria.

Understand the user story

The better we understand the business objective and the overall goal of the story, the better job we do at creating the acceptance criteria. Understanding why the business wants something is essential here.

Be specific

Avoid vague terms like “elegant” website or “fast” load time. Define measurable outcomes such as “less than a two-second load time.”

Make it testable

QA should be able to devise test cases against each criterion and provide an overall strategy and plan for testing.

Keep it concise

Some teams might overthink and create too many acceptance criteria around a user story. This bloats the workload unnecessarily. A skilled team is able to discern between the must-haves and nice-to-haves and balance those against business needs, budget, and time constraints.

Acceptance criteria examples

Example 1: Login feature for a professional networking app

The system must be able to withstand and prevent brute-force attacks.

• After 5 failed login attempts, the account is locked for 30 minutes
• An email notification is sent to the user

Example 2: Toy store e-commerce website checkout

Users must be able to apply a discount at checkout.

• Provided a valid promo code is entered, the cart value adjusts accordingly
• If the code is already used or expired, then an error message appears

Best practices for writing effective acceptance criteria

As with anything, writing effective acceptance criteria comes with practice. Here are a few tips to get you started:

• Keep it simple: Avoid overly technical language that alienates non-technical stakeholders.
• Focus on outcomes: Define what the system should do, not how it should do it.
• Review and refine: Update criteria as new insights emerge during development.

Demos can change into arguments very fast as informal acceptance criteria become blame-game fuel.

Pitfalls to avoid when working with acceptance criteria

A couple of pitfalls should be avoided while you work with your team:

• Outdated acceptance criteria: Regularly update documentation, especially in high-churn teams.
• Undocumented acceptance criteria: Make sure each criterion is well documented, aligned, and communicated before development begins.

Conclusion

By now, you’ll have come to appreciate why setting good acceptance criteria is so essential for product teams. Software quality primarily hinges on a team’s ability to work coherently to come up with well-crafted user stories and their subsequent acceptance criteria. By investing in training and driving best practices, you can streamline development and improve software reliability at your organization.

Interested in learning more techniques geared toward improving software quality? Head over to the Tricentis learning portal for more.

This post was written by Ali Mannan Tirmizi. Ali is a senior DevOps manager and specializes in SaaS copywriting. He holds a degree in electrical engineering and physics and has held several leadership positions in the manufacturing IT, DevOps, and social impact domains.