TL;DR: If you’re looking to INVEST in your user stories by making them Negotiable, then for Pete’s sake don’t write them like requirements.
Code by Contract
As someone who prefers the Build-Measure-Learn approach to discovering and then delivering the right thing of value at the right time, nothing is scarier than reading the following words from section 4.3.1 of the IEEE Std 830–1998, Recommended Practice for Software Requirements Specifications (SRS):
An SRS is correct if, and only if, every requirement stated therein is one that the software shall meet.
It reminds me of an instance out of my life before product management, when I made a living as a developer who’d coax data exchanges between any two devices sharing a wire. One day a well meaning project manager arrived at my workstation holding about half-a ream of freshly laser-printed paper.
Clenching the tome about 18″ above my desk, said project person said with all the humanity of a DMV desk clerk, “You won’t get into trouble if you follow the plan precisely to the letter …” making sure to drop his handiwork so it would provide an emphatic THUMP precisely on his words “… follow the plan …”
Needless to say, while said comprehensive documentation was unambiguous, complete, consistent, verifiable, and even modifiable, the plan as prescribed turned out to be a cruel work of software integration fiction the first time variant data was exchanged.
N is for Negotiable
In contrast, as product managers we need to think and act differently when it comes to requirements. The concept of the user story empowers us to do this using an approach Alistair Cockburn described back in 1998,
“A story card is a promise for a conversation.”
With this in mind, we need to write frame our stories in such a way that members of our development teams feel free to converse, challenge, and even change the story so that eventually we maximize the value of the feature delivered while maximizing the amount of work not done.
We want to craft our user stories so that while they paint a persona-driven picture of ‘what’ that encourages empathy and action on behalf of the customer.
We want to enable UX to say something along the lines of “I think this story is addressing a symptom rather than a cause.”
We want to encourage our QA team members to ask “How do we know we’ve delivered this?”
We want to avoid highly prescriptive novellas on ‘how’ in favor of just enough detail to understand the ‘why,’ so that developers feel free to ask that a single story be split.
We want to be positioned so we can entertain a request by the team to initiate a small spike, so the story (or stories) can be more effectively estimated and delivered in sprint-sized batches at the last responsible moment.
If nothing else, we can INVEST in making our user stories Negotiable by keeping in mind these synonyms for conversation: “collaboration, communication, conference, debate, dialog, discourse, discussions, exchange, observation, query.”
What Others are Saying
- “User Stories are not a contract. They are not meant to be precise, detailed specifications of a feature. They should not be fixed in stone.” — Kelly Waters
- “What is crucially important is to capture any and all agreements made during collaboration and negotiations into the related user stories, so everyone is on the same page and agreements are not lost.” — BrainConcert
- “A final difference between user stories and IEEE 830–style requirements specifications is that with the latter the cost of each requirement is not made visible until all the requirements are written.” — Mike Cohn
- “Elephants are not giraffes and user stories are not requirements.” — Per Lundholm
- “Why it pays to INVEST in your user stories part 1 of 6: Independent” — yours truly