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.
…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.
“…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:
- FilterGroupsBySubjectArea, and
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.