User Stories versus Use Cases
This content is syndicated from by Kelly Waters. To view the original post in full, click here.
Scott Sehlhorst from Tyner Blain is one of my favourite bloggers. He's written an excellent post about User Stories versus Use Cases.
When I first used Use Cases, I loved them...
I loved the fact they gave such a clear description of a feature, and the fact that each Use Case could stand alone. They made it really easy to move cards representing the Use Cases around the whiteboard, as a way of managing progress.
But I also found Use Cases a little complicated. When you look closely, they're not that complicated really. But they tend to need a Business Analyst to write them. And they tend to be a bit off-putting for end users or business people.
I think this is partly because they use quite a bit of jargon. And particularly when faced with a lot of them, all up-front, to be signed off and used against them in a change control process later.
So when I came across User Stories, I loved them even more. They seemed to offer all the things I loved about Use Cases, but in a simpler, lighter and easier-to-use format. They're easier to write. And they're much easier for end users or business people to work with.
Scott is right though. User Stories leave out a lot of important details. They leave these details out deliberately, relying on a conversation with the product owner to clarify the details at the time of development. They rely on this collaboration. Developing small increments, getting feedback and iterating, rather than having more detailed documentation up-front. Without this collaboration, I agree, User Stories could be problematic.
Having said that, if the product owner won't collaborate on User Stories throughout development, why would they collaborate on Use Cases during the analysis? In the end, whichever approach you prefer, active user involvement is imperative!