Start with acceptance criteria

Also known as

Don't start without acceptance criteria.

Motivation

Make sure everyone has common understanding before building anything. Acceptance criteria should be part of your Definition of Ready. You're not done when acceptance criteria aren't automated.

All software built should be made for a reason. It's valuable to capture that reason. Normal (Word) documents are not enough to work from. They leave room for ambiguity.

Applicability

It's best to think about acceptance criteria for a feature/story, before the implementation starts. Preferably before the sprint starts, so the team has as much information about the feature as possible.

Application

When defining your acceptance criteria, think about the “What”: What should it do? Not: how should it be done. The How is about implementing the feature. We're searching for What it should do in terms of business functionality.

Before you start to work on a feature or user story it's good to know what the expectation of the business or product owner is about that particular feature. Make this as formal as possible. Preferably to the extend that it can be automated in a breeze.

Think about examples of how a particular feature can be used. How are you going to demo it once it's built?

Consequences

As a consequence business and development team will have a much better understanding about what the application will do. Developers on the other hand have a better understanding about what the business is trying to achieve with a particular feature and can help the business find better ways to achieve their goal.

Samples

Specification by Example is one way to deal with acceptance criteria in terms of (usage) examples.

References

The Xebia Essentials Cards

This page is part of the Xebia Essentials, a pack of flash cards about Software Development Done Right. You can get your own deck of Essentials cards in the Xebia store (sold out).

Buy Now