26 March 2009

User Story a 2-bit Use Case?

A new member of Agile .Net Practitioners, a LinkedIn group I moderate, asked

When you talk about User Stories, how does that differ from Use Cases?

Alistair Cockburn said
A User Story is to a Use Case as a gazelle is to a gazebo
a catchy one-liner he later amended to
A User Story is the title of one scenario whereas a Use Case is the contents of multiple scenarios
A slightly better statement to which Jim Standley replied
...a story is a promise to have a conversation and a use case is the record of the conversation.
By all accounts Ward Cunningham coined the term User Story. By Ward's definition, a User Story is
...a story about how the system is supposed to solve a problem or support a business process. Each user story is written on a story card, and represents a chunk of functionality that is coherent in some way to the customer.
For those wondering how a User Story differs from a Use Case, see Ward's User Story and Use Case Comparison. A pithy excerpt from Ward's page comes from Alistair Cockburn:

"...Think of a User Story as a Use Case at 2 bits of precision. Bit 1 of precision names the goal of the use case, Bit 2 adds the main scenario. Bit 3 adds the failure conditions, Bit 4 adds the failure actions. Bit 5 adds data description of the in/out data. I would put Catalysis at a 6th bit
of precision, as they include a model also of the recipient of the message...."


My Story Paradigm

If a paradigm is 20 cents, here's a pair of dimes for you about user stories straight from the trenches of C-Sharpistan.

Following the advice of David Hussman, every developer's mantra could be to coax their business customers into "thinking and talking in tests".

For me, the most crucial item in a story is a list of business-stated test statements; preferably using mutually recognizable, and previously agreed upon, personae. For example, tell me, in concise, granular statements what “Albert the Anonymous Guest” can do:
  1. Albert the Anonymous Guest may view a list of all groups that are internally designated as “Open Access”.
  2. Albert the Anonymous Guest can filter groups by Subject Area.
  3. Albert the Anonymous Guest can sort groups by Name.
These statements rapidly translate into unit tests like
  • ViewGroupsByAccess,
  • FilterGroupsBySubjectArea, and
  • SortGroupsByNames.
What constitutes done is an ongoing challenge in agile. A list of business-stated test statements makes done rather cut and dried.

If my test harness can demonstrate and pass the aforementioned tests, the story is complete and Bob's yer Uncle.