A couple of months ago, I purchased “User Storied Applied” by Mike Cohn. I glanced through it, primarily looking for similarities between use cases and user stories to give me a point of reference. I found my point of reference pretty quickly in chapter 12 in a section titled “User Stories Are Not Use Cases”. In this section the author indicates that there are 4 major differences between use cases and user stories 1) their scope 2) their level of completeness and 3) their longevity and 4) the proclivity to include UI details in use cases.
In my experience, use case scope has presented difficulty in the SDLC. Yes, use cases are structured and sized to deliver business value but the business value in a single use case could take the entire SDLC to complete. This is a problem in use case driven projects because project tracking is based on use case completeness. I have found that using use case scenarios instead of use cases is helpful (if everyone on the project is on board) and our author agrees “that a user story is similar to a single scenario of a use case” as long as the scenario represents a successful path through the use case.
There are a couple of solutions that address the problem of use case completeness. One that I am particularly fond of is the use of use case outlines that are completed JIT. For example, in the inception phase the actors and use cases are discovered and documented in the use case model. Each of the use cases are then outlined to discover their basic flow as well as their alternate flows – each given only a name and brief description – and only those flows that have been identified as architecturally significant are detailed. But… 80 to 90% of the remaining flows are completely detailed prior to the beginning of the construction phase.
Use case longevity has proved to be even more frustrating to me. Not so much because the use case was used throughout the SDLC, but because so many resources (people & time) are used to create them, organizations tend to want to keep them around even longer and use them as post production artifacts too.
Keep UI details out of the use case! How many times have I said that? I probably cannot count for it has been a struggle in every single project I have been involved in. (Anybody out there remember me saying that!?)
So why user stories? I think the best reason is to eliminate use case documents. Project team members could not get on board with using use case scenarios because the scenarios were imbedded in use case documents; they just could not mentally decouple a scenario from its parent. And if there is no use case document there is no place to stick a UI specification. And, even more importantly, if there is no use case document there is no propensity to keep it and maintain it for all eternity. The author also lists 4 other reasons 1) they emphasize verbal rather than written communication 2) they are comprehensible to all parties 3) they are the right size for planning and 4) they work for iterative development.