Agile Journal has a good article about the ‘Definition of Ready‘.
In my experience, acceptance criteria on story cards is the most commonly overlooked aspect of running an agile project.
At the time they’re created, the story cards seem to be well defined. ‘Build a contact form’ seems fairly self-explanatory. But what’s not included is what a working contact form looks like.
When this story card goes into testing, or UAT, defects start to come back. There are the usual ‘looks bad in IE’ defects, and then you start to get “contact email doesn’t include logo”. Then along the way defects like “recipient list needs to include department managers” start to appear, and the development team is starts to realise that this has nothing to do with building a contact form. This is how zombie story cards are created – requirements that can never be completed.
By including acceptance criteria, you also define precisely what functionality the story card contains. This frames the development tasks and gives people confidence in what needs to be done.
With acceptance criteria, when the Internet Explorer display bugs come in, those can be fixed as part of the design acceptance criteria. The contact email defects could easily be a different story card, and be handled separately, allowing for the contact form to be closed successfully.