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.