In a recent article on AgileConnection, Allan Kelly wrote the following about the timing of writing acceptance criteria (acceptance tests) for user stories:
The Right Time to Define
I am frequently asked, “When should we write the acceptance criteria?” Sometimes programmers resist giving an effort estimate for a story unless they can see the ACs—sometimes detailed ACs, at that. However, there is little point in POs (and testers) spending time on ACs until stories are about to be scheduled. After all, if ACs take hours to write and the story is not scheduled, their time is wasted.
Also, if ACs are added but then the story doesn’t get scheduled for a year, by that time the story and the ACs may have changed. Because old criteria are in place, it can be easy to overlook these potentially important changes.
This update is from the STP conference I’m attending in Denver the week of November 3, 2014. Software Test Professionals is a conference mostly focused towards testing, so the slant of all of the talks is that lens or perspective. That being said, the agile topics are by definition broader and more whole-team centered.
I just attended a session by Jeff Porter where he was exploring agile practices in a talk entitled: Agile – Where the Rubber Hits the Road.
Now let me start by saying that I liked Jeff’s talk. It was very pragmatic and practical. He simply shared what they were doing at FamilySearch.org. Practitioner reports like this one truly enhance the state of practice in the agile community.
Introduction
There are several terms used for it within agile contexts. Sometimes you hear:
- Done
- Definition-of-Done or DoD
- Done-Ness Criteria
- Acceptance Criteria
- Release Criteria
Sometimes you even hear it repeated, as in: This story isn’t complete until its—“Done…Done…Done”.
Apparently the more “done’s” you have, the more emphasis there is on completeness. Although I don’t think I’ve heard more than four “done” used in a row.
It happens to me on a weekly basis. I’m teaching a class on how to write User Stories. Usually it’s part of my Product Owner workshop. We’re happily writing stories for an iPad application simulation. Typically halfway thru the exercise someone raises their hand because they’re struggling with the format of a purely technical story. Quite often they don’t know how to frame the “user” clause and are stuck there in their writing.
My first recommendation is often to tell them to skip it. I tell them that the “As a” and the “So that” clauses are usually quite different for technically related stories. I just ask them to quantify the need (technically), in clear English with perhaps a couple of sentences, and then move on.
