One of the biggest challenges that prevent teams from reaching their goals and growing products is misalignment. Today, teams try to build a culture of autonomy and a culture of delegation beyond merely delegating tasks. However, the freedom that comes with autonomy involves both responsibility and alignment. In our previous article, we described how User Stories might help teams to achieve this alignment between all the participants in the SDLC process. Now, let’s take a deep dive into one of the tools that help User Stories keep the entire team on the same page.

Failure to meet deadlines and low-quality product releases are often caused by miscommunication and misalignment. 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. In contrast, those with low PM maturity levels exceeded this number by 47%. Let’s define how acceptance criteria can help with the issue and help your team achieve goals.

Defining Acceptance Criteria

With so many moving parts, it's essential to have a clear and concise set of objectives that everyone can agree on.

Acceptance criteria (AC) help to ensure that all stakeholders are working towards the same goal by defining what conditions a software product should satisfy so that we can release it to customers. In addition, AC help to identify potential risks early on in the SDLC, saving time and money in the long run. Whether you have a seasoned team of experts in software development or are just getting started, make sure to include them in your next project for a successful outcome. AC are used to:

  • determine whether a User Story is ready for release;
  • assess the quality level of this product before release;
  • make sure the product meets the needs of the customer’s business;
  • keep User Stories clear, understandable, and achievable.

AC help verify that a User Story meets all of the necessary requirements. If any of the AC are not met, the feature should be improved before it can be accepted and released.

Agile also uses a similar tool – Definition of Done – to measure the readiness of features to be released. The difference between them can be difficult to understand. However, it is critical for Product Owners to know the distinction. This is so they do not mistake one set of requirements for another in order to complete their tasks on time with quality standards maintained throughout all stages.

The Definition Of Done (DoD) defines what criteria every product increment has to meet before it can be considered finished, according to Scrum Guide. The difference between DoD and AC is that the former applies to all user stories. However, AC vary for each User Story depending on what requirements need to be fulfilled.

Techstack case

At Techstack, we ensure our Agile processes help the team provide maximum value to products. This helps to ensure that not only is the software functioning as intended but that it also meets the expectations of the customer or client. By having a clear and shared understanding of what needs to be accomplished, we can avoid misinterpretations and ensure that everyone is on the same page. As a result, DoD aligns the team and reduces the chance of different interpretations of the same requirements.

What are Acceptance Criteria Used For?

AC are imperative for any project in order to ensure that the feature meets all the necessary requirements. They provide a clear, concise, and measurable definition of what needs to be delivered in order to mark the product feature as a success. Software development acceptance criteria should be decided upon before work on the feature begins. They can be used to assess whether a deliverable is complete and fit for purpose or used as a tool for communication between different stakeholders involved in the project.

  • Expectation management. Acceptable AC should have clear boundaries so that there is no ambiguity in interpretation. The answer should be either yes/no or pass/fail.
  • Scope changes management. Scope changes are a major risk for product engineering teams. If you don't have clear goals from the beginning, it can be difficult to stay on track with your work. This can result in unexpected delays or costs along the way that could throw off any schedule going forward.
  • Commitment instrument. It is imperative to arrive at a shared understanding with the client. If they feel like you don’t meet all of your commitments, well-documented acceptance criteria will address any ambiguity that might exist.
  • Estimation optimization. The more specific a team is about the boundaries of their tasks, the higher the chances that they will have an accurate estimate of how long each task should take. AC help to set and align with these boundaries.
  • Testing optimization. AC help you to write test cases, check whether your system performs as expected, and provide an improvement or modification guide.

Who Writes Acceptance Criteria and When?

Usually,  Product Owners (POs) are responsible of creating an acceptance criteria to ensure that the team would deliver user stories according to the customer's or end user's needs, rarely – the Scrum team. As such, they are in a good position to determine what AC should be met, and hence build an acceptance criteria list for the team to follow.

To exclude mistakes and low-quality development, AC should be created prior to development work beginning on a User Story so that all parties have a shared understanding of what remains to be delivered. Ideally, AC should be created and understood by the team before the beginning of the sprint. This ensures that everyone on the team is on the same page regarding what needs to be accomplished.

How to Write a Good Acceptance Criteria

AC can be used to test the product before release. They should be clear, concise, understandable, and measurable so that it is possible to determine if they have been met or not. They should also be achievable, meaning that they are realistic given the resources and timeframe of the project. In practice, AC consist largely of test scenarios that aim at confirming whether or not the application works as expected.

AC can be revisited and updated during development as more information about the product becomes known. However, all changes to AC should be agreed upon by PO and other stakeholders before being implemented.

Acceptance Criteria Types and Structures

AC can be scenarios or rules. In rare cases, teams introduce their own versions of AC structures to fit their specific needs. Here, we’ll dig deeper into the most popular formats.

Both types are key to making sure that features are actually useful to users. AC scenarios help to ensure that features work as intended in real-world settings. In contrast, rule-oriented ones help to ensure that features meet minimum standards for performance and reliability.

Scenario-oriented acceptance criteria

This type of approach is useful for complex features that will be used in multiple ways. This type of AC list helps to ensure that the final product will help users in a variety of scenarios. For example, if the development team is working on a new search feature, the scenario-oriented AC might specify that the feature must be able to handle misspellings and return results from different parts of the website. In addition, it can also help to Identify potential problems during development, allowing team members to make changes before the product is released. The common formula that represents the AC scenario is as follows:

  • Given {pre-condition}
  • When {action}
  • Then {results}

Using this approach, testers start by writing test cases for each feature. They then use these test cases to drive the development process, ensuring that each feature meets the required standards. This approach has a plethora of benefits, including improved coverage and reduced development time.

Rule-based acceptance criteria format

Some backlog items need another approach to writing AC rather than the Given/When/Then for objective reasons.

  • System-level requirements (such as beta testing and alpha releases with volatile data sets) wouldn’t benefit from Given/When/Then structures;
  • Given/When/Then cannot describe UX specifics that can be critically important;
  • There is simply no need to cover details about test scenarios to your customers.

AC rules, unlike previous ones, aim to specify conditions to be met in order for the feature to be considered complete. For the search feature example, AC rules might determine that it must be able to handle at least 10 simultaneous searches and return results within 2 seconds.

Examples of Acceptance Criteria

Let’s examine several AC to learn what differs in these structures and choose what fits you best. (By the way, for learning how to minimize the chance of missed deadlines, read our guide to writing high-value User Stories blog.)

Quick Summary of Acceptance Criteria

One of the challenges that prevent teams from reaching business goals and growing products is misalignment. Without AC, there is a risk that the story will be poorly understood or implemented, leading to frustration on both sides. With AC in place, however, both the customer and the Scrum team have confidence that the product will meet their needs.

  • Backlog items must meet AC to be considered complete.
  • Scrum teams typically agree on them after the PO sets them.
  • By clearly defining the accepted criteria upfront, agile teams can avoid scope creep and failure to meet stakeholder expectations.

By following these guidelines, AC help deliver product functionality that users will actually find useful.

Frequently Asked Questions

What are AC and when are they applicable?

The term “AC” refers to the requirements a Unit of Work must meet in order to be released. AC help set task boundaries and ensure alignment between stakeholders. By having an aligned vision of what needs to be accomplished, everyone can work together more effectively to create a successful final product. But, in order to achieve positive outcomes, POs need to know how to create an acceptance criteria.

Why are AC points important for my product?

Without a clear understanding of what you're trying to achieve, it's all too easy for your team to build something that doesn't quite hit the mark. This can lead to costly reworks and delays, as well as frustration on both sides. By contrast, if you take the time to establish firm points of a feature to align upfront, you can be confident that your team will build something that meets your expectations and can be readily tested. This in turn can save you time and money down the line. So if you're looking to get the most out of your product, be sure to give some thought to your AC.

What are the benefits of having clear AC?

Missed deadlines are a common frustration in product development. In many cases, these problems can be traced back to a lack of clear AC. By setting expectations and boundaries, AC lists reduce the need for changes and postponements. They also optimize testing and estimation processes, making it easier to identify potential problems early on. Businesses can save themselves a lot of time and frustration further down the line.