Are we done yet?
Determining Completion Criteria using Agile
Methodologies
... a n d h o w w il l we ever k n o w ?

What is “DONE”?
“Nothing ever gets done around here!”
“When are you going to be done with that?”
“That’s not how I wanted that done!”
“How can I tell when it’s done?”

What is “DONE”?
Determining completion is part of the
specification of a task.
How do we write specifications?
Us e r St o r ie
s!

More User Stories?!?
Each “User Story” describes a single aspect of the
final product - a feature specification - in simple,
easy to read language.
Feature specifications should also contain a
number of “Acceptance Tests” that define the
acceptable behavior of the feature.
Tests should not be overly complicated, just as
Stories are not overly detailed, and can be added
to as iterations progress.

When do we do this?
Before, during, and after programming the
feature
Prior to an iteration, usually in the Sprint
Planning session
Whenever the development team and client talk
about the User Stories they’ve written

Do I have to write them?
Ideally written by the client, since they
understand the desired behavior best.
Designed to expose the assumptions that the
client is making about the software.
May need augmentation from the developers to
address technical details omitted or overlooked.
NOT a replacement for Unit Testing!

This sounds familiar...
Work with the client to write Acceptance Tests
for each User Story that describe the desired
behavior before programming the feature.
You mean like...
ent! S CRU
Te s t- Dr i ve n De ve l o pm
Be h av i o r-Dr i
M!
ve n De ve l o pm
ent!
De at h by A g ile B uz z wo rd s !

Can I have an example?
User Story Card
A user can log in to the system and view her
dashboard. If she’s a guest, she can register
instead.
• “username” must be an email address
• “password” should be really secure
• don’t create profiles for bad email addresses
• users get three tries at the password
• offer an automated password recovery
8 points

What does that mean?
The “username” field needs email validation
The “password” field needs a good “password
strength” validation
Supplied email addresses must be confirmed
through some process before a user profile is
created
Possible pitfalls?

Another example please...
User Story Card
A user can pay for a course with a credit card.
• we only accept Visa, MC, Discover, and
Amex... no “Diner’s Club” BS
• before running the transaction:
• check the card number and type
• check the expiration date
• test for over-limit purchases
13 points

Okay, break that down...
Card types, numbers, and expiration dates must
be validated before they are submitted to the
payment gateway
Some card types will not be accepted by the
system, regardless of their validity
Watch out for purchases that exceed the
available limit on the card!

How do I program that?
Unit Testing is only a start. Test the minutiae of
predictable misbehavior with good Unit Tests.
Behavior-Driven Tests are better, because the
tests should correspond to the Acceptance Tests
written by the client.
testing:
* itShouldAcceptVisa(): pass!
* itShouldAcceptMasterCard(): pass!
* itShouldntAcceptDinersClub(): pass!

Where do I learn more?
User Stories Applied: For Agile Software
Development by Mike Cohn (ISBN 0-321-20568-5)
Extreme Programming: Acceptance Testing
Acceptance Testing on wikipedia.org
http://www.slideshare.net/al_the_x

Who is this guy?
linkedin.com/in/althex
twitter.com/al_the_x
github.com/al-the-x
slideshare.net/al_the_x