Use Cases and User Stories

While listening to ARCast recently, I heard the following:

‘And stories are pretty much placeholders for conversations’

The speaker was Claudio Perrone, who was talking with Ron Jacobs about Agile development in Dublin.

This comment highlights one key difference between Use Cases *and *User Stories.

Use Cases are documentation of a conversation that has already happened. User Stories are documentation of a conversation that needs to happen.

This contrast highlights the key weakness of Use Cases: because the conversation happens well before (weeks if not months) any coding occurs, all of the information required by the developer has to be written down. Anything not committed to paper (or screen) is lost.

User Stories, on the other hand, occur just as the code is being written. Every relevant aspect of the conversation makes the transition from the developers head into the code.

As an approach, Use cases insert an extra step into the process, an intermediary between the business user and the developer. This runs the risks of ambiguity and misinterpretation, and should only be done if it adds significant value.

A good Business Analyst can provide this value - by improving consistency and predictability, by reconciling needs between different business users, and so on.

So, which should you use: Use Cases or User Stories?

Your decision shouldn’t be motivated by any of the religious arguments in this area, but simply by this: Will I gain significant value from having a Business Analyst act as an intermediary between the business and my developers?

Use Cases are expensive - they take significant amounts of time and resource, and should be avoided unless they provide significant value.

Take heed though: When Use Cases could provide you with significant value, failing to use them is likely to lead you into a whole new world of pain.

Make your choice with care.