Acceptance criteria act as predetermined conditions that must be met to successfully accept project deliverables, products, or specific elements like sprint user stories or test cases. Collaboratively defining clear and concise acceptance criteria with the end user helps mitigate the risk of development falling short of expectations. These criteria foster a shared understanding of desired outcomes and facilitate effective communication among stakeholders, ensuring that the final deliverables align with the agreed-upon requirements. By implementing well-defined acceptance criteria early on, project planning and execution are enhanced, leading to a smoother and more successful outcome.

Defining Done vs. Acceptance Criteria: Spotting the Contrast

The Definition of Done establishes a set of standards that must be met to consider a project or a specific level of work, such as user stories, as complete. It serves as a universal benchmark, promoting a shared understanding of quality and completeness within the team. If the criteria are defined at the user story level, they apply to all stories within the project. The Definition of Done fosters consistency and clarity regarding project expectations, facilitating effective collaboration and minimizing potential misunderstandings.

In contrast, Acceptance Criteria focus on the specific requirements that must be fulfilled for individual deliverables or features to be accepted by the end user. These criteria are collaboratively defined with the user and provide a clear understanding of what constitutes a satisfactory outcome for a particular task or feature. While the Definition of Done sets the overall standards for project completion, Acceptance Criteria offer detailed guidelines for evaluating and accepting specific deliverables, ensuring alignment with the user’s expectations.

Both the Definition of Done and Acceptance Criteria are indispensable project management tools. They promote transparency, accountability, and the delivery of high-quality results by establishing a framework for evaluating the fulfillment of needs and providing measurable assessment of compliance with requirements.

The Significance of Acceptance Criteria in Project Success

Acceptance Criteria play a crucial role in projects by offering precise guidelines to assess the quality and completeness of deliverables. Through the establishment of specific criteria that must be fulfilled, projects gain the ability to effectively measure value and pinpoint the moment when that value can be achieved.

Acceptance Criteria play a vital role in fostering a shared understanding between the project team and stakeholders regarding the expectations and requirements for the final product. They establish a common vision of what constitutes a successful outcome, ensuring everyone involved is on the same page.

With well-defined Acceptance Criteria, projects can efficiently assess and validate deliverables, mitigating the risk of misunderstandings or misalignments. This clarity streamlines the development process, allowing the project team to concentrate on meeting the specified criteria. As a result, the project can be successfully completed and accepted.

Even if you can express the requirement or user story clearly, it is unlikely to encompass all perspectives and subjective interpretations. Usually, a requirement or story requires analysis to ensure proper comprehension. Even when the analysis involves the requirement owner, story persona, or end-user directly, there is no assurance that the final outcome will align precisely with the original vision.

There are numerous development constraints that can contribute to this discrepancy, but not all of them are easily grasped by individuals outside the development team. One fundamental constraint could be the developers’ experience and capabilities, as well as their understanding of the end user’s context. Questions like “What will their code be used for?” and “How will it be used and how often?” are crucial considerations.

Analyzing these points helps developers increase the likelihood of meeting the intended needs. However, meeting the needs does not automatically guarantee acceptance. This can result in costly rework and excessive iterations of the developed work, leading to the dreaded scope creep. Other reasons why projects require acceptance criteria include:

• Refining non-functional requirements: Clear guidance is established for the project team regarding how the software or infrastructure should behave in specific scenarios or under certain conditions, even when the unexpected occurs (negative scenarios);
• Facilitating quality assurance and testing: Acceptance criteria enable consistency and traceability throughout the discovery and analysis of requirements, development, and final testing before release.

Establishing this consistency throughout the project lifecycle serves as a foundation that aligns the project team, users, and requirement owners, leading to a shared understanding. This cohesion plays a vital role in helping the project meet its deadlines. During the testing phase, it becomes crucial to independently verify whether the developer has successfully met the acceptance criteria in the final product. This verification process serves as a key assurance step before the product is released.

A Guide to Writing Acceptance Criteria in Your Project

To write acceptance criteria for your project, the developer should assess relevant data points that establish user context during the requirements or story analysis phase of each iteration. In traditional projects, this assessment is typically carried out by a business analyst and documented in a hierarchical format, such as:

Heading

1.1 Requirement

1.1.1 Acceptance Criteria 1

1.1.2 Acceptance Criteria 2

and so on.

This process involves working through each scenario in an interview-like format with the user and documenting each point. It’s important to strike a balance and not make the process overly exhaustive, as it’s impossible to eliminate all risks. Additionally, the acceptance criteria should be realistic and achievable.

Agile projects follow a similar approach, but it can be simpler since the user story already establishes some user context and desired outcomes. The Agile process typically follows the hierarchy of Epic > Story > Acceptance Criteria, and this step must be completed before the development team begins their work. While it may seem obvious, this step is often overlooked in many projects.

Projects that encounter quality assurance or user acceptance issues often have deficiencies in their acceptance criteria or, worse, lack them entirely. To embed the practice of defining acceptance criteria into your pre-development process, consider implementing a step that requires the completion of acceptance criteria before estimation.

Each project may approach defining acceptance criteria slightly differently. If your project is at least making an effort to document acceptance criteria, you’re on the right track. However, like any project process, there are various approaches to completing this task, and their effectiveness may vary depending on the project or product being developed.

There are various high-level approaches that projects can employ to guide the development of acceptance criteria. Here are two examples:

Scenario-Based Approach: Given-When-Then Formula

The Given-When-Then formula, pioneered by Dan North in Behaviour Driven Development, enables the development team, testers, and users to establish a shared understanding of how an application should behave in different interactions.

For instance, let’s consider the User Story: “As a customer of the eShopping site, I want to add a product to my shopping cart so I can purchase it.” One scenario that could be explored for acceptance criteria is “Adding to Shopping Cart” (note that there may be multiple scenarios within this user story).

Using the Given-When-Then formula, the team can structure the acceptance criteria as follows:

• Given: Establishes the context or preconditions that should exist before taking action. For example, “Given I have navigated to the page of the product I wish to select on the eShopping site.”
• When: Describes the action taken by the user and the corresponding input data. For example, “When I click ‘add to cart’…”
• Then: Specifies the expected outcome of the action, including the output data and the postcondition. For example, “Then I will see a counter appear on the shopping cart icon at the top right of my page, displaying the sum of all products I have added to the cart in that session.”

By applying the Given-When-Then formula, the team can systematically break down the user story into various scenarios that need to be tested and validated, ensuring the user’s requirements are met. This approach facilitates independent testing of application behavior, improves quality, and reduces rework before release.

Checklist or Rule-Based Approach

In certain cases, the Given-When-Then formula may not be suitable or necessary for some acceptance criteria. Instead, a straightforward set of rules can be defined to observe the application’s behavior. This can be represented as a checklist or bullet list of rules that developers can validate as they complete their work.

Continuing with the same User Story of the eShopping site, the developer can create a list of agreed-upon rules and generate multiple scenarios, such as:

• Clicking on the product image should navigate to the product page;
• The ‘add to cart’ button should be displayed on the right side of the product image and information;
• The ‘add to cart’ button should remain visible as I scroll down the product information page;
• Clicking the ‘add to cart’ button should increment a counter on the shopping cart icon;
• The shopping cart icon should be permanently displayed at the top right of the page;
• The shopping cart counter should accumulate every additional product selected until checkout.

These rules serve as a guideline for developers to ensure that the desired behavior is implemented correctly.

By using either of these approaches, projects can establish effective acceptance criteria that align with user expectations and contribute to the successful delivery of high-quality products.

Conclusion

In conclusion, acceptance criteria can be adapted to suit the needs of your project using various proven methods. The essential goal is to establish a shared language and understanding among users, developers, and testers. By doing so, you can achieve better outcomes, mitigate the risks of cost overruns and rework, and foster greater support and early adoption of the released changes.

Take a moment to evaluate your projects and ensure that acceptance criteria are in place. If they are lacking, implement processes before your next sprint to ensure their inclusion. You’ll be pleasantly surprised by the positive impact that well-defined acceptance criteria can have.

FAQ