Once a month I hold a Scrum Lunch and Learn, where I present on a topic dealing with Scrum, while group members enjoy some delicious Thai food. This month, I spoke about user stories. A user story is the format we use for requirements, and looks like this:
As [some type of user] I can [do something] in order to [achieve some benefit].
Here’s an example:
As a Site Visitor I can create an account in order to become a member of the site.
The benefits of user stories are that they emphasize verbal communication, are understood by both suits and geeks, defer decisions and details, and work with iterative development. By themselves though, they are vague, and purposefully so. There could be a lot or a little involved in a user signing up for the site. Most importantly, my definition of done for this story could be, and is most likely, very different from your definition of done. Recall the adage “you don’t know what you want until you see what you don’t want.” In software development, this is very true. So how can we help to ensure that what we produce for our clients is what they want?
Enter acceptance criteria, a.k.a. acceptance tests.
Acceptance criteria are where “done” is defined. And guess who writes those? The client. So how do they do it? Here’s an example. Let’s review our user story:
As a Site Visitor I can create an account in order to become a member of the site.
Our acceptance criteria might include:
- A user should enter an email address and a password
- Test that both the email address and password are entered (not blank)
- Test that the email address is in a valid format
- Test that the password is at least 6 characters
To me, that’s pretty clear. I know what I need to code, I know what tests I need to write, and the client knows what to expect when I push it to the testing server.
In short, acceptance criteria, written by the client as part of a user story, defines done.
