Acceptance criteria is what every test and the final product should be checked against.

Imagine an architect designing a skyscraper…

Without knowing why it’s being built or who will be using it.

And then suppose the construction company takes this uninformed blueprint and begins building.

Do you think the skyscraper will be a success?

Or a failure?

Most likely, it would be entirely useless and have to be torn down and rebuilt from the blueprint on up.

That’s exactly what can happen to your software.

Without knowing who you’re building the software for, it won’t be well-received.

Without knowing what you need to include in the software (and be able to tell when you have everything you need to satisfy customers), it won’t be functional.

Which means you need two things:

1. A user story
2. Acceptance criteria

We’re going to cover both today, including why they’re important, how to construct them, and how to know when you’re doing it right.

Let’s start with user stories.

What is a User Story?

A user story is the primary first step to excellent software development. It’s often used for teams practice the Agile framework, but it’s essential regardless of your development methodology.

The purpose is to fully understand what problem the software is solving, if it’s a problem worth solving (that is, if people want it solved), and how exactly the software will solve the stated problem.

User stories are typically written like this:

As a (type of user), I want (some action) so that (goal/result/value is achieved).

Without this knowledge, you really can’t begin any meaningful software development. It would be divorced from the end user – the most important person in this equation.

User stories should be your go-to method for identifying user needs.

The goal is to ensure the development team actually solves real problems instead of just meeting arbitrary requirements.

Too often teams start with What, and forget about Who and Why.

In short, user stories require the following:

• A clear statement of the problem to be solved (but NOT the solution).
• A clear statement about who the end user is and why they need the problem solved.
• To focus on end user needs in the simplest, most concise form.
• To highlight the most essential pieces of software that must be included at the moment (knowing further development will take place).

And to construct user stories properly, teams usually rely on the three C’s:

• Card – a slim, written version of the user story that captures the essence of the story while acknowledging that everything hasn’t been worked out yet, and that the development team and business will discover more as they’re working on it.
• Conversation – a collaborative discussion between the Product Owner, stakeholders, and the development team (preferably in person) to evolve the initial user story by looking at documentation, automation tests, and more.
• Confirmation – The Product Owner confirms that each user story and the software that was created as a result is considered “done” and that the software passes acceptance tests.

Once the user story is complete, teams move to creating acceptance criteria.

What is Acceptance Criteria?

Acceptance criteria is a formal list of requirements that match a corresponding user story.

A problem can be seen from many angles and a user story can be fulfilled in virtually infinite ways.

Acceptance criteria distills those possibilities into clear, straightforward requirements that must be present in the final product.

The criteria specifically states the conditions for fulfilling the user story and satisfying the Product Owner (your customer), the end user, and the software or hardware your product will interact or integrate with.

Acceptance criteria has to be so specific that each criterion can either pass or fail during testing.

Any criteria that is too ambiguous has to be refined. For example, wanting your app to be “awesome and engaging” tells developers almost nothing.

At the end of the day, acceptance criteria sets the “definition of done” and should eliminate as many misunderstandings as possible – aiming for absolute clarity.

When (And Why) Should You Create Acceptance Criteria?

Always always always write acceptance criteria BEFORE development begins.

User stories are helpful guides, but they’re not specific enough to execute.

Here’s exactly why you need to create acceptance criteria:

• Define boundaries – acceptance criteria helps teams feel out the boundaries of their user story. Meaning, it confirms they’re going to match customer expectations and desires.
• Reach consensus – acceptance criteria helps development teams sync up with the Product Owner’s expectations. This ensures development knows precisely what conditions they’re expected to meet.
• Improve tests – acceptance criteria is necessary to determine when acceptance tests go well or not, positive or negative, or if the product works as it was intended to. This means it has to have a clear “pass or fail” standard.

Who Writes Acceptance Criteria?

The Product Owner (client) may write the acceptance criteria, the development team will write it.

But even in the case of the Product Owner writing the criteria, the development team must review it and make sure it clearly lays out expectations, and that there are no constraints or inconsistencies.

With that said, getting the Product Owner’s input as much as possible is key to delivering a well-received product. And if the client has experience or know-how when it comes to writing acceptance criteria, then that’s one less thing development teams need to shoulder.

If the development team is tasked with writing the acceptance criteria solely, then you should bring on a project manager or Quality Assurance specialist to assist.

What are the Types of Acceptance Criteria?

There are 3 main types of acceptance criteria that we outline below.

Scenario-Oriented Acceptance Criteria

The scenario-oriented approach is laid out like this:

• Given some precondition…
• When I do some action…
• Then I expect some result.

Often called the GWT (given, when, then) formula.

This approach was borrowed from the behavior-driven development (BDD) process. It defines the beginning and the end of testing for a particular feature.

This is especially helpful in limiting the amount of time spent on writing test cases. This takes care of it upfront.

Every individual acceptance criterion will have the following statements:

• Scenario – the name of behavior described.
• Given – the beginning of scenario.
• When – the action taken by user.
• Then – the outcome of the action taken by user.
• And – the continuation of the previous statements until scenario is complete.

The goal is to describe every conceivable action a user can take to a complete a task and achieve a specific outcome.

Rule-Oriented Acceptance Criteria

There are instances when GWT won’t work for you.

For example:

• The development team doesn’t require precise details of the test scenarios.
• You’re trying to describe the design and the user experience.
• Your user story describes the system level functionality.

The rule-oriented approach to acceptance criteria usually takes the form of a list of rules that describe the behavior of the product. Based on the rules, you create specific scenarios.

Rule-oriented acceptance criteria may look like this:

• Search field is located on top right bar.
• Search starts when user clicks “Search.”
• Search field contains a placeholder with grey-colored text, “What are you looking for?”
• And so on.

Custom Formats

In many other cases, neither of those two methods work and development teams and/or Product Owners need to create a custom format for acceptance criteria.

What these formats look like can only be determined by the client and development team.

How Do You Know If Your Acceptance Criteria is…Acceptable?

After knowing how to write acceptance criteria, you have to ensure you wrote it correctly.

Knowing what acceptance criteria should be is very different from actually writing them.

There are 3 characteristics of well-written acceptance criteria:

1. Defined Pass/Fail Results

We touched on this briefly earlier, but want to expand on it.

Without clear criteria, effective testing is nearly impossible. And having more problems with the product down the line is almost inevitable.

Testable criteria allows you to confirm that the desired conditions have been met.

Plus, ambiguity prolongs testing and development, prolonging the rate at which the product is brought to market, increasing costs and making you less competitive.

If a criterion states “reduce the number of entries available in the drop-down menus,” the developer won’t know how many entries to reduce it to, or if one menu needs 3 reductions and another menu needs 5.

They’ll have to rely on their gut instincts and experience with the product.

A tester will have to do the same.

And eventually, the problem will go back to the Product Owner and have to repeated.

All of this wasted time and effort can be resolved through absolute clarity and specificity.

2. Concise Criteria

Strive for simplicity and succinctness when writing acceptance criteria.

You kind of have to approach it like any serious author would, by keeping the audience in mind and writing for total comprehension from the readers.

Long-winded descriptions and unnecessary jargon will only bog down your message and make it more difficult for developers and testers to decipher the criteria.

Furthermore, it’s very easy to overlook crucial details in a sea of text.

So hesitate before blaming others for their lack of “careful reading” and examine how the criteria was written, first.

3. Shared Understanding

Getting everyone on the same page is the primary goal in the early stages of software development.

Without cohesion between team members, the entire enterprise can devolve into arguments, confusion, and missed opportunities. All of which delays the final product.

One way to foster a shared vision and mission is to encourage every team member to take part in the acceptance criteria writing process.

This allows everyone to interact with the criteria and develop a deeper understanding naturally. But it also allows many people to offer criticism, ask questions, and refine the criteria before it’s executed.

What Should Be Included in Acceptance Criteria?

Acceptance criteria should never be a rehash of user stories or other design documents.

It needs to stand on its own and should include the following:

• Functional Criteria – specific tasks, functions, and processes, such as “a user is able to share documents with other users.”
• Non-functional Criteria – conditions the final product must meet that aren’t necessarily actionable, like design elements. Example: “Start Free Trial button has #f70000 as background color.”
• Performance Criteria – qualities such as response time, written as “app loads all functions after being selected in less than 2 seconds.”

Take the Guesswork out of Constructing Acceptance Criteria

Acceptance criteria is just one part of operating an effective Agile software development team.

There are many other factors to make Agile and acceptance criteria operate efficiently.

It takes the dedication of your team, organizational leaders, and top executives to make a new software development model work consistently for you and your clients.

Getting everyone onboard isn’t easy when you’re doing it alone. That’s where we come in.

ATC specializes in Agile consulting. We can help you:

• Analyze your organization and its current processes and provide you with a roadmap and recommendations for adopting or improving Agile capabilities.
• Facilitate your organization’s transformation from legacy methods to a mix of Agile practices and principles to redesign processes, reinvent roles, and restructure incentives for optimal adaptability and performance.
• Scale the Agile system throughout your entire organization, codifying the framework and helping you implement and sustain Agile initiatives across multi-team projects and platforms.

Reach out today to discover how to make Agile finally work in your business.