Good Practice in Writing Acceptance Criteria

Type: Rules
Sources: Dan North, Chris Matts, Dave Astels, my own practice.

Gist

To explain, how to produce useful acceptance criteria.
acceptance criteria (AC) DEFINED AS a means to express the important tests for a product or system from a behavioral point of view.
Note: Writing acceptance criteria is not about specifying tests and not even about preparing for writing test cases. Instead, it's writing specifications of behavior.

Rules and Notes

R1: Use the standard form "given [Context] when [Event, Feature, Function] then [(expected) Outcome]".

R2: Write one AC for every single expected result. If you end up with more results per AC, try making the contexts more specific. Gist: By keeping the AC small and focused, they are easier to refactor.

R3: Don't just have one AC per feature, that says "everything turns out perfect". You need one per specific context.
Note: This rule seems ridiculously self-evident, but my recent experience while working with an "experienced" requirements analyst shows that it isn't…

Costs, Savings

What does it take to implement those rules? What does it give?

Side effects

Is there anything that happend or will happen as one implements the rules? This relates to both wanted and unwanted effects ('unwanted' does not imply 'negative').

Related Pages

rating: +1+x

If you want to know more about a topic, simply tag the article with a 'morePlease' or 'examplesPlease' tag!

BlinkListblogmarksdel.icio.usdiggFarkfeedmelinksFurlLinkaGoGoNewsVineNetvouzRedditYahooMyWebFacebook

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License