Tell Me a (Short) Story

There’s an implied assumption in waterfall methodologies that there is value in creating requirement specifications for development. 

Aside from the already discussed costs associated with delay, there are a few inherent flaws in assuming that dedicating time early in the development process to detailed requirements adds value:

1)       We must know who the users are

2)       Users must know what they want

3)       Users must be able to communicate what they want

I challenge each of these underlying assumptions.  The first difficulty is one that all projects must overcome to find success.  Chapters could be written on how to find and involve your users.  I’d maintain, however, that nothing brings out users like releasing a product into the wild.  Wrap a beta release with a forum or wiki and you’ll soon discover users you never considered. 

The second is another where whole books are written about how to “elicit” or “capture” requirements from users.  It sounds, perhaps appropriately, as if we are trying to coax them like a shy kitten from the corners of users minds.  In my experience, unless you are porting an existing application to a new platform, users will only have a notion of what they need to be successful.  Show them something that they can use, and they start to understand the possibilities.

Finally, how many times have we heard, “but, that’s not what I meant.”  Even if users had a clear vision of their needs they may not communicate it clearly with words.  Even if they communicated clearly, a product owner or business analyst may not understand it.  Even if they understood it, the developer may not interpret it correctly. And so on, like the childhood game of telephone.

So, what’s a product owner to do:  Collect stores like a good investigative reporter.  Stories are the voice of your customers. Use stories to help define the product vision.  Use them to define the product’s value and to give it a personality.  Use stories to define who will use your product.  Create personas for each user role – give them names, add pictures and a life and spell out why they love the product.  Use stories to create initial estimates of how big the effort is.  Use stories to determine priorities – absolute priorities about what is critical for the users to gain value and relative priorities to help plan releases.  Use stories as a reminder to have another conversation when it is time to develop how a feature will work.

Use the format from Mike Cohn’s book User Stories Applied:

As a <role>, I want to <goal> in order to <value>

But, only gather enough stories with just enough detail to accomplish the above tasks.  Stories are the raw materials of development.  They should stay high-level and short until they are released into an iteration.  After stories are released, develop them to gain abundant detail.  Only then should you add the details: how will they look, how will they integrate with already created features, what architecture is needed to support them, what tasks must be done to create them, what acceptance criteria and test scenarios are needed to error proof them, and what as-built and user documentation is needed to support them. 

Thus, my third “law of development physics”:  The value of requirements increases as its production release becomes imminent. Or, you know what you need when you see it, until then, make up a good story.