Use Cases and User Stories

Jeremy Miller writes that he prefers user stories over use cases--and I basically agree with him. Mainly because user stories are more fine-grained, which leads to making them more "estimateable" and manageable than use cases.

However, having used both, there's one thing use cases do better than user stories -- eliciting related scenarios. When you write a use case that covers a business scenario, the use case template makes you think about variations and exceptions. If you're not careful to proceed in a structured manner when you try to think of a theme of user stories, you might miss some.

One important point regarding use cases is that you don't have to treat the use case as a single monolithic block. When you work with use cases it doesn't have to mean that you sign-off use cases in a Waterfall-ish manner -- that is, something that has to do with your development methodology.

You can develop use cases incrementally; that is, only do some of the use cases per "release". You can also elaborate use cases iteratively by elaborating/identifying some of the scenarios in each iteration (in a manner similar to user stories). I have
successfully used both incremental and iterative use case elaborations on several projects and I find this approach useful. I even wrote a ( paper summarizing my use cases experience a few years ago. (Warning! More than 60 pages.)

In fact, even today I find it useful to use both tools when I would usually start with identifying a user story and writing that down. Then map it to a use case (either an existing or new one) -- where a use case roughly equals a user story theme. As I mentioned previously, I can them identify more user stories and add them to the product backlog. The use case stays as a skeleton with links to the user stories and helps provide context to individual use stories. (Okay, so that isn't a use case in the traditional sense, but I find it useful anyway.)

Generally speaking, it is important to note that while it is tempting to equate a user story with a scenario in a use case, that isn't always correct. Sometimes a user story would be a step in a use case, and sometimes a story is shared by several use cases -- since a fine-grained feature that delivers business value can be used in many business processes, which is what use cases are oriented to.

As an aside, if you have a project where you do have to write all the requirements up-front (like they won't change anyway), then I find that use cases are superior to IEEE 830 style requirements ("The system shall..."). But hey, that's another story.

Posted by Arnon Rotem-Gal-Oz at 04:05 PM  Permalink