Last week we asked our developers anonymously why we use various agile methods. The results for acceptance criteria (below) were roughly in-line with more official definitions, but interesting nonetheless.

Typically our team writes conditions of satisfaction at the story level only, after which the product owner reviews them. As reflected in their responses below, the team would prefer that the product owner wrote all the conditions of satisfaction.

Verifies (Acceptance Criteria / Conditions of Satisfaction):

• Details how features function so they can be QAd. The Product Owner signs off on them to ensure he is ok with how features work.
• Ensures that the team knows when it is done and that features work as they should.
• Used to define what done means, and what should be built.
• Drives development by the customer. Confirms that the dev team understands the requirements.
• Supposed to be PO defined requirements, currently works with the developers emulating the PO’s desires. Helps to keep consistent understanding of features among devs.
• Used to understand what we are building.
• Supposed to ensure that the programmer knows the requirements. Actually shows the business owner what was implemented.
• Used by the QAer so that he knows what to test.
• Theoretically defines problems to be solved and the end result. At the end, used to guarantee that the application does what we said it should do (similar to a checklist of features)
• Define system requirements and acceptance criteria. Helps devs think of how the system should be/will be used. Indicates to business owner that the team understands the problem.

How do your teams view the reasons for writing up conditions of satisfaction? Is there a perceived disconnect between theory and practice?