Acceptance Criteria

What are acceptance criteria in agile methodologies?

Agile methodologies encourage teams to focus more on the user and to more efficiently and effectively provide solutions to their specific needs and desires. The success of an agile project depends on understanding the customer’s needs and delivering software or products that align perfectly with them. That’s why these criteria should be written from the user’s perspective and defined on the back of solid user research.

eBook

Mastering Prioritization

Read now

Then, the acceptance criteria should be agreed upon between the development team and client, if applicable. Better still, if you are building a product or software solution on behalf of a client, writing the criteria should be a collaborative experience.

What are acceptance criteria used for?

Setting acceptance criteria can help streamline a project, from start to finish. For example, these criteria improve the process of:

Setting boundaries

Acceptance criteria are one of the key ways to keep a development team on track, and to define the scope of a project. They set the limits and the boundaries of a user story, and give teams the ability to confirm when a product works properly, or if a piece of software does what the user needs it to do.

Reaching agreements

A set of clear criteria is, more or less, an agreement between team and client about what the function of the product is going to be, and when it can be defined as ‘done’. Solid acceptance criteria make sure that everyone is working on the same page, so as to avoid any misunderstanding or confusion. 

Planning effectively

Acceptance criteria provide a framework for the user story and a simple way of portioning up a project into individual tasks. This, in turn, helps to build a far more effective set of plans, as well as more accurate strategizing and effort estimation.

Testing thoroughly

Most importantly, acceptance criteria form the basis of all product testing. 

The criteria provide teams with the necessary elements that need to be tested, and a project or iteration can only be defined as ‘complete’ once every criterion has been tested and accepted. This ensures that the testing process is as successful and as productive as possible. 

How do acceptance criteria help teams?

Find the time to align the team around a set of targets now, and you’ll reap the benefits later. For example, acceptance criteria add value by:

Keeping the team focused and on-track

Acceptance criteria offer development teams something tangible to keep them on track, and something to constantly keep them laser-focused on providing solutions for their users. 

Ensuring the user story is completed successfully 

The user story becomes the first priority of the development process, and the criteria give teams a cast-iron way of ensuring that the user story is completed successfully. 

Encouraging communication, and acceptance criteria helps manage expectations 

Acceptance criteria are also a great way to promote good collaboration and communication between teams and clients and to help developers manage the expectations of their customers. 

Clarifying user stories 

On their own, user stories can be quite general — vague even — and are certainly open to interpretation. 

Acceptance criteria help to provide clarity to these stories: setting out and agreeing on the scope beforehand, cutting out ambiguous outcomes or goals, and helping to keep a project on track. 

How to write acceptance criteria?

In theory, anyone on either side, project team or client, could write the acceptance criteria. For obvious reasons, though, a good understanding of software development, criteria writing and the task at hand will be required. 

In practice, the acceptance criteria are usually written by the client, and then agreed by the project team. But the best criteria will be written in collaboration, with both sides having input into the process, and agreeing on the necessary scope and requirements of the project together.  

It is, understandably, vital that the acceptance criteria are set out before the development process gets started, and not retro-fitted after the project is already underway. 

The criteria should guide the process, not the other way around, and the agreement between client and team should be about the least time-consuming way to deliver against all of the client’s — and user’s — needs.

As with all planning and strategy, the key elements of a good set of acceptance criteria are that they are achievable, manageable, well-defined and sensible. They should provide enough detail that they can’t be misconstrued or misrepresented, but also include enough flexibility that the team can remain properly agile. 

Examples of user stories with acceptance criteria

Acceptance criteria and user stories tend to be written in a reasonably formulaic way, using a ‘Given, When, Then’ format or an ‘As a [user] I can [function] so that [result]’ pathway. 

Essentially, the user story creates a set of conditions, which end up ultimately defining the acceptance criteria.

An example would be creating an app that brings up local bus timetables, where the pathway would look something like:

“As a passenger, I can see the timetables of local buses so I can get to my destination on time”

In this case, the acceptance criteria for the app would be similar to: 

• The app locates the passenger

• The local routes are displayed

• The relevant timetables are displayed

• The journey time and/or arrival time are calculated

In this scenario, the ‘Given, When, Then’ format would produce a story like:

“Given a user’s location and the current time, when they search for a local bus route then the relevant timetables, journey times, and destinations are displayed”.