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.

4 Replies to “Tell Me a (Short) Story”

  1. First I have to say that I’m neutral when it comes to methodologies, but a software project without requirements specifications?

    I agree that a lot of people are not very good at the above, but does that mean we have to eliminate this step altogether? It’s all about following a certain tested and proven document (for example, here’s one on the TRS in Web Projects).

    I think the constant communication with the client is a good idea and will increase the chance for a project’s success, but starting with a solid requirements specifications is, IMO, always good, even if the requirements are changing over time.


    1. This is a common miss-perception of agile. The only thing that changes is when requirements are detailed. In traditional methodologies, requirements are normally fully detailed before any development begins. In agile, the stores prior to development are in enough detail to estimate effort and priority. The detailed requirements are created as close to when they will be developed as possible. At that point, they can be less formal since their lifespan is shorter and the developer is closer to them. And, most importantly, they can be more accurate since learning has happened during the development process and in early review of the application during past iterations.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: