Brief Guide on How to Effectively Craft Acceptance Criteria for User Stories

In the Agile framework of software development, the user story entails a description of features determining the needed goal from the end-user perspective. In order to craft a great user story meeting market requirements and satisfying users’ expectations, acceptance criteria have to be elaborated upon in advance. To prevent issues from happening across the project life cycle and eliminate misconceptions between stakeholders, managers, and end-users, project teams must clearly define the purpose of the product provided in the software requirements documentation. Ensuring concise product acceptance criteria (AC), you clarify the conditions a specific user story must meet.

So why do you need acceptance criteria? Let’s formulate this question in another way: what would happen if my business didn’t cover acceptance criteria? There will be a high possibility of poor communication which is the primary contributor to the project failure.

Due to poor requirements management, 47% of projects are prone to a fiasco. Therefore, it is of high importance to establish synchronization with project requirements and the development teams to deliver the desired functionality. Acceptance criteria will play here a role of a mediator throughout the stages of product development facilitating effective communication between team members to avoid unpredicted outcomes at the end of the development stage.

So What Are the Acceptance Criteria?

Acceptance criteria (AC) are a set of predetermined requirements that must be complied with to ensure that all scenarios are considered and user stories are accomplished subsequently. Since different team members are involved in the process of product development, it is important to eliminate the gaps that are standing in the way between the client vision and the development delivery. With acceptance criteria, each particular feature in the user story is defined to ensure that deliverables meet the client’s requirements.

Why Do You Need Acceptance Criteria?

For cross-functional teams applying Agile methodology, it is critical to clearly define AC in the product backlogs as they can serve as a guarantee of your product representation to the end-user and a pillar for development teams to rely on. Let’s outline the key benefits your product teams can obtain while leveraging acceptance criteria in the user stories:

• Development teams are in coherence and relevancy with the client. AC plays a significant role in the smooth collaboration between the client and the development team who definitely have to be on the same page to yield desired outcomes.
• AC help to define user story scope and reduce ambiguity. By that said, we mean that acceptance criteria facilitate the clear-cut vision of the user story giving the understanding of the functionality from the beginning to the finish so that you know whether the story is “done”.
• With acceptance criteria, the testing process is streamlined. Each acceptance criterion is translated into manual or automated test cases with pass/fail results.
• You are able to properly and accurately evaluate features. AC scenarios foster the correct estimation and planning of the user stories.

How to Write Acceptance Criteria: Formats and Types

There is no precise answer to this question since each team individually defines the best procedure and type of generating acceptance criteria. There are different formats available, however, the most commonly used are the following:

• Scenario-oriented (Given-When-Then)
• Rule-oriented (Checklist criteria)

Scenario-Oriented Format

GWT (Given/When/Then) approach illustrates the sequence of each criterion. Given (prerequisite), when (the action is performed), then (the result is achieved). It is worth mentioning that the GWT approach is derived from BDD (behavior-driven development) which facilitates the process by focusing on the user’s perspective and value thanks to the writing in the first person. By that we mean, from the end user’s viewpoint, you can easily streamline the navigation of the software product as well as simplify development delivery.

So let’s analyze this approach by providing some acceptance criteria examples. First, let’s see the template for the standard user story:

As (I – a user), I want (to take some action), so that (I can achieve the desired outcome).

Now let’s proceed with some concrete scenarios for a specific user story.

[EXAMPLE 1]

User story: As a user, I want to be able to select the product on the online shop, so that I can proceed with purchasing the product.

Scenario: Successful purchasing the product on Amazon

• Given: The user navigated to the product page on Amazon
• When: The user clicks “add to cart”
• Then: The system navigates the user to the checkout
• Then: Offers to select the shipping address
• Then: The user places the order.

[EXAMPLE 2]

User story: As a guest, I want to be able to sign up for the app via a Google account, so that I will be able to access my account quickly.

Scenario: Quick signing up for the app

• Given: The user navigates to the Sign-up page
• When: The user clicks on the Google button
• Then: The system offers to choose an account
• And: The user enters his credentials.

Rule-Oriented Format

While a scenario-oriented format for writing user story acceptance criteria is suitable for complex workflows with many entry and exit points, rule-oriented acceptance criteria that are represented in the format of a bullet list or a checklist, is a perfect option for project scope creep that is limited without the need to scale up. When selecting the format for writing acceptance criteria, you have to define what features are needed to be covered, if there is a need for accurate details of the scenarios, and whether you need clear-cut statements or more precise branches of answers.

Rule-oriented acceptance criteria will fit your project if you need a number of strict rules to depict system-level functionality. Let’s take a look at how a rule-oriented approach can help fulfill the user actions required:

[EXAMPLE ]

User story: As a user, I want to get a demo of the product on the web page.

1. The hello bar is located at the top of the page.
2. By clicking the red button, a user is moved to the contact form.
3. The contact form is located at the end of the page.
4. The user must enter his name, phone number, and email address to get the link to the demo product.
5. The user clicks the button “Get a demo now” and the link is opened in the new tab.

This list can be prolonged according to the specifics of particular functionality. As for UX, while applying a rule-oriented approach, there is no freedom in design. This means that rule-oriented acceptance criteria are geared at manifesting only one use case without the possibility to customize a new user experience. So that you need to periodically make updates toward the alignment between the current UX and the new one and adjust AC.

Who Is Responsible for Agile Acceptance Criteria Creation?

There are no strict requirements on who will be in charge of the AC writing process. Basically, the product owner or product manager is responsible for AC generation while creating the product backlog. However, there are multiple members who will be consumers. Therefore, during sprint planning it is essential to involve other team members to specify the requirements of the client and ensure that they are complied with.

For example, UX designers can be involved in the process to establish the coherence of users’ goals and designs. Quality assurance representatives and business analysts help identify discrepancies and dependencies to further enhance the AC quality. Once the development team joins, they can estimate AC from the point of view of code logic and data structures which will foster the final delivery.

Also, if the client is tech-savvy and equipped with technical knowledge of software development, they can drive the wheel. But still, all the company staff and stakeholders should make their own contribution toward fine-tuning the acceptance criteria documentation.

Free Acceptance Criteria Templates

To free you up from overwhelming technical preparation, we outlined some of the alternatives of downloadable user story templates with acceptance criteria.

• Aha! offers various templates: simple user story, epic user story, thematic user story, SAFe user story in the format of Excel or Word doc.
• With PowerSlides, you can craft simple user stories with standard statements represented in six dynamic designs.
• Product Plan template allows for five sections: title, priority, estimate, user story, and acceptance criteria.

How to Make Project Acceptance Criteria Effective: Challenges and Best Practices

Without a well-elaborated approach toward producing acceptance criteria in users’ stories, the result in the best-case scenario will be achieved with delays or in the worst way – will harm the whole development process. To be able to manage the acceptance criteria process of writing, first of all, you need to estimate what challenges you can experience on this path.

1. Undefined user roles. As we mentioned before, acceptance criteria in user stories have to be focused on the end customer and be provided from their perspective.
2. The statements are not precise. That means that each statement has a clear pass or fail result without branching to alternative ones.
3. Technology-accentuated. The goal of AC is to formulate possible paths of user journey by crafting pass/fail scenarios for each use case. Moreover, this documentation has to be acceptable to anyone in the team. Therefore, stick to the feature-centric approach rather than outlining tech details that can be hard to comprehend.
4. Only one member is involved in the AC production. Regular meetups with business analysts, QAs, development teams, and project managers are the key to the successful implementation of new functionalities. Actually, within the Agile approach, short staged release cycles and testing are broken down into several sprints and iteration sessions. Acceptance criteria that you write for your user stories have, therefore, to be collaborated by all members of your team to facilitate a smooth and seamless release cycle.

Follow these guidelines to make this process methodical and effective. The acceptance criteria must be:

• Balanced. It means that covering too many details can lead you to bogging down in the minutia of multiple excessive tasks resulting in delayed delivery time. And at the same time, with limited criteria, not all user actions will be covered. This can affect the holistic view of the user journey. Therefore, make your criteria actionable, achievable, measurable, and full-fledged moderately.
• Documented. They should be documented at the early stages of the software development process in order to identify the users’ requirements in advance and effectively plan the technical implementation.
• Comprehended by all stakeholders. The main point here is to be able to interpret technical terminology and simplify it to convey the message straightforwardly, in plain language that will be accessible to everyone without a technical background.
• Testable. With simple and straightforward criteria, the results of the test cannot be ambiguous – only pass/fail or yes/no. Testable AC help developers be sure that the story is completed.
• Complied with specific stylistic form. Formulate sentences using active voice in the first person. Also, avoid negative constructions with the participle “no/not”, excessive conjunctions, and complex statements that can overwhelm the members. The more understandable language you use in your acceptance criteria, the fewer efforts will be needed for interpretation to capture the bottom line.

Wrap Up

In the form of predefined conditions and requirements, acceptance criteria significantly impact the effectiveness of user stories for your software development project. Without AC, the scope of the project will be not defined, customer expectations will be ambiguous, and outcomes will be not achieved in the way your client is striving for. Your end-user perspective has to be the priority while you work on AC since they define the conditions each user story must satisfy.

Contact us if you have any questions on how to write acceptance criteria for your specific project. Our experts will help you polish the requirements by taking into account your particular business goals and visions.