A while back, I made the claim in one of the Agile LinkedIn groups that writing use cases was one aspect of being a professional software developer. That naturally received a bunch of push back from people who felt use cases were too heavyweight. Many people claimed user stories are more than sufficient for most software teams. While I agree with most of the sentiments expressed about why user stories are superior, I still believe use cases are the mark of professional software engineering and their absence is a sign that a software project is in trouble.
Imagine my surprise when I stumbled across this old rant from Alistair Cockburn, the author of one of the best books on use cases, about people confusing use cases with user stories. In his rant, Alistair defines quite succinctly the difference between use case and user story.
A user story is synonymous with “feature” as used in the 1990s, a marker for what is to be built, fine-grained enough to fit into modern iteration/sprint periods. A use case provides a contextual view of what is to be built, serving to bind the organization together, among other things.
I really like this description since it identifies how the two tools are quite separate and how each provides value each. If you are interested in spending a little more time with the topic of use cases, Alistair explains why he continues to work with use cases.