It is with words as with sunbeams. The more they are condensed, the deeper they burn. ~Robert Southey
Dude has to know who he’s selling to ~David Hussman
|Doug the Delivery Dude|
|Product Owner’s Do List||Developer’s Test|
Story Card Wrap
As a User I need to __________ so that ________.
As Persona I need to Story Title so thatdo item – acceptance criterion
My tea kettle is whistling with more than lukewarm ideas on how we might use Google Wave for collaborative software projects.
To separate the steam from the high-pitched whistle of market evangelism…
Google Wave is a communication platform.
The Google Wave model promises to be a comfortable fit for seeding and feeding post-agile software projects. We might use Google Waves for
I like its threaded conversations of wavelets, blips, and drag-and-drop multimedia. Some Google Wave features that should make collaborative software projects easier are
- Bots and Gadgets Developers can embed gadgets and build robots that automate tasks within a Wave. A robot might read the content of a wave and then perform an action.
- Drag-and-Drop Sharing – Unlike clunky email attachments, you just drag-and-drop screen prints, wire-frames, buttons, stock photos, etc. on a Wave.
- Wiki-like, Hopefully Better – Anything within a Wave is editable by others. One may correct, append, or add commentary. One can only hope this is where project artifacts live rather than die (as with many project Wikis).
- Real-Time – See what your teammate is typing, character-by-character, unless it’s planning poker – in which case you’ll have to close your eyes.
- Playback – Playback any part of a Wave to see what the SME actually said about how something works.
The immediacy of instant messaging, combined with the richness of an anabolic Wiki, might prove to be a worthy collaboration tool. I like the concept of having team-member participation in threaded conversations (a traditional bulletin board), but also having features like playback and custom-robots that interrogate Wave content to perform actions.
The possibilities heat my water to boiling point. Robots are like having another person participate in a Google Wave conversation, except that they’re automated and they operate on the content of a wave. All extensible by common day-laborers like me.
The actions spawned by a bot might range from notifications like build failed or single sign-on test succeeded to spawning wavelets of unit test methods that are peppered with scenarios plucked from business-side requirements, discussions, and feature assertions.
Imagine a bot that parsed a business thread for Behavior Driven Development keywords like
As persona [X}
I want [Y]
so that [Z]
AND, parsed a business thread for scenario keywords like
Given initial context,
When an event occurs,
then ensure some outcomes.
then spit out a unit test methods?
Challenges to Adoption
Widespread adoption of a technology-driven phenomena like Google Wave will likely have to first hurdle cognitive and social models in search of digestible user metaphors (see Adina Levin’s excellent post Google Wave: still in the lab, potentially mindbending for adoption).
Many of the operational metaphors that make things easy for users to understand simply don’t exist for Wave yet. The Wave model mashes the familiar (email threads, wiki documents, and streaming communication) together. Instant messaging in your favorite messaging client is an easy model to follow. It is a simple post, response, & repeat. Will a multimedia, multi-participant Wave be so straight-forward? How will users find content efficiently? How will users invited into to a Wave conversation get up to speed with the other participants? Wave touts a replay feature, but is that the most efficient thread content primer?
Try Tweeting your user story as if conciseness mattered.
Brevity and conciseness are the parents of correction.
The Twitter Constraint is a 140-character limit Twitter imposes on Tweets. If you constrain yourself to follow the first tenant of DUA (i.e., Don’t Use Abbreviations), LOL, and you experiment with the 140-character limit, it might make you write better user stories.
But don’t carry brevity to extremes. Ballou also cautions
Never be so brief as to become obscure.
As a [user role], I want to [goal], so I can [reason].
But don’t let something like a template constrain you. It’s a guide; a starting point. Don’t be dogmatic – about anything.
There are zillions of posts advising you about Writing Good User Stories.
Discover the language what works for you and your team. For example, I like personas, like Help-desk Hector, that encapsulate the user role.
Vigorous story* writing is concise. A story* should contain no unnecessary words…for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts.
–William Strunk, Jr.
* The word story was inserted by me.
Perhaps you’ll discover you can cross-cut your way to the crux without sawing off the scaffold of meaning.
I leave you in the capable hands of Sir Winston Churchill (1874-1965):
This report, by its very length, defends itself against the risk of being read.
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:
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.