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
- 7 rules for high effectiveness
- why and how to state the credibility of estimations
- 7 useful viewpoints for task planning oriented towards quick results
If you want to know more about a topic, simply tag the article with a 'morePlease' or 'examplesPlease' tag!
