For development teams who work using agile methodologies, acceptance criteria are used to finalize and complete the user story. A set of targets that must be met, they are used to define the scope of a user story, and to set the limits and framework of the tasks that must be fulfilled before it can be marked as ‘done’.
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 acceptance criteria should be written from the user’s perspective, and defined off the back of solid user research.
Then, the acceptance criteria should be agreed 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 acceptance criteria should be a collaborative experience.
Setting acceptance criteria can help streamline a project, from start to finish. For example, acceptance criteria improve the process of:
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.
A set of clear acceptance 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.
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.
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 criteria has been tested and accepted. This ensures that the testing process is as successful and as productive as possible.
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:
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.
The user story becomes the first priority of the development process, and the acceptance criteria gives teams a cast-iron way of ensuring that the user story is completed successfully.
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.
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 the scope beforehand, cutting out ambiguous outcomes or goals, and helping to keep a project on track.
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 acceptance 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.
Acceptance criteria and user stories tend to be written in a reasonably formulaic way, using a ‘Given, When, Then’ format, or a ‘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 is 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”.