A user story is not a use case.
That might seem as obvious as saying "A door is not a cat", but there's enough scope for confusion - not just in the similar names - that user stories and use cases are often used interchangeably (when describing what to do next in a software project) when they probably shouldn't be.
Alistair Cockburn sums it up nicely: A user story is to a use case as a gazelle is to a gazebo.
But also:
A user story is not a story.
In other words - this is not a user story:
"The user types in a story and clicks Submit. The system publishes it to the website so that other users can read it."
It's really a use case. But it also doesn't help that there are many definitions of "use case", and many opinions on how much detail should go into one. But generally, the one consistent aspect of a use case is that it's a narrative: a description of a user's journey through the UI, and the system's responses as he clicks and types his way along: "The user does this or that; the system displays XYZ data in response. Next, the user does this... etc." In other words, the text of a use case is really a story.
A user story, meanwhile, is anything but a narrative. And this, I think, is the main source of the confusion. The name "user story" implies a story - a narrative. And it really doesn't help matters that the name is often shortened to "story". But a user story is anything but a story - at least in the narrative sense. I could see people starting to call narrative-based requirements "stories", but it's a false etymology, as they say.
As soon as a requirement takes a narrative form, it's no longer a "user story" in the defined sense... which I think is confusing as hell. As soon as the requirement follows a narrative form, describing a user's interaction with the UI, it's a use case.
In other words:
A user story is not a story.
A use case IS an actual user story, but not a "user story".
A user story is really a high-level requirement - usually (but not always) a functional requirement: that is, a note about a particular needed capability.
The generally accepted way to write a user story is to follow the "Who/What/Why" form, usually written as: "As a [who], I want [what], so that [why]." And that's it. Any further definition or detail or discourse is deferred to a later stage in the process. In XP this "later stage" is some supposed future conversation with the customer once development is underway (I'll withhold comment on this particular approach, as I've commented aplenty on it elsewhere!).
In other processes such as ICONIX/DDT, the "later stage" is the elaboration of the functional requirements into behavioural requirements (aka use cases). Use cases are where the hard questions on system behaviour are asked; and the process deliberately gives you a hard time if you try to proceed without getting those questions answered first.
The reason I'm digressing into "process wars" is because this raises an important point about what makes a use case what it is (and how that differs from a user story). Note that the basis of a use case is the functional requirement that it came from:
- A functional requirement defines a needed capability, and a set of use cases define how the system will provide that capability to the end-user.
- A user story defines a needed capability.
There, fundamentally, is the difference between a use case and a user story. And hopefully that also illustrates why it can be dangerous to use the terms interchangeably. A user story referred to as a "use case" implies that all the behavioural exploration and definition is done, and the team can begin coding, answering any further questions as they go (and we all know that's the way to ensure a project is never completed).
So that's a fair amount of pseudo-linguistic analysis on use cases and user stories, and quasi-existentialist pictures of pipes... but is there a point to it? Actually yes: if you hear someone stating offhandedly that the next step in your project is to "write the use cases and/or user stories", then you know that something (or someone) has become seriously mixed up. You might feasibly have both in one project - where user stories are the high-level requirements, and use cases describe the behaviour that will fulfil those requirements - but they're definitely not interchangeable.
Comments