User Story And Use Case Comparison
User Story And Use Case ComparisonWhat's the difference between a UserStory and a UseCase? Two words for the same thing?
After several years of debating this question and seeing both in use, I now think they have nothing in common other than their first three letters. See below... -- AlistairCockburn
I coined the term UserStory, as far as I know, so I'll tell you what I had in mind.
My purpose is to maintain a balance of political power between business and development. Use cases as I have seen them used are complex and formal enough that business doesn't want to touch them. This leads to development asking all the questions and writing down all the answers and taking responsibility for the resulting corpus. Business is reduced to sitting on the other side of the table and pointing.
I want a very different dynamic. I want business to feel ownership of and take responsibility for the care and maintenance of "the requirements". I want business to feel comfortable making priority decisions about the requirements. I want business to feel free to add new requirements, and add new detail to existing requirements, as development progresses (see also ProgrammingIsSocialLearning).
This requires a form of expression that is more approachable than a formalized use case. It also helps if the communication medium is something approachable, like IndexCards. So I say, "Tell me the stories of what the system will do. Write down the name of the story and a paragraph or two."
My experience is that business, properly trained, takes to managing stories like the proverbial duck to the equally proverbial water. Business has to be trained not to just throw new stories into the CommitmentSchedule or WorkQueue without a DevelopmentEstimate and the necessary reshuffling. Development has to be trained to begin examining stories enough ahead of IterationPlanning so learning the next level of detail does not become a bottleneck or a risk.
So, to answer your first question, yes and no. The idea of specifying the behavior of the system from an outside perspective, and using those specifications throughout the life of the system is the same. The execution is quite different. Comments, Alistair, oh guru of use cases? -- KentBeck
Note --- the following text was written in the late 1990s. I leave it intact since it was part of a historical discussion typical at the time, and many people are likely to go down that path. My position has changed since then, i.e., I think there is nothing in common between a user story and a use case except the first 3 letters of the name (see for example, http://alistair.cockburn.us/index.php/A_user_story_is_to_a_use_case_as_a_gazelle_is_to_a_gazebo). Some other people are doing different things under the name "user story" in 2007, different from the XP style user story (see http://alistair.cockburn.us/index.php/Talk:The_new_user_story_is_a_real_story). --AlistairCockburn (2007)
Think of a User Story as a Use Case at 2 bits of precision. Bit 1 of precision names the goal of the use case, Bit 2 adds the main scenario. Bit 3 adds the failure conditions, Bit 4 adds the failure actions. Bit 5 adds data description of the in/out data. I would put Catalysis at a 6th bit of precision, as they include a model also of the recipient of the message. In the CrystalMethodology family differently founded projects use use cases at different levels of precision. A methodologically light project uses User Stories, a methodologically heavier project uses Use Cases to 4 bits of precision, and Catalysis uses 6 bits of precision.
I have seen Kent's user stories. For C3 and many other projects they are great. C3 is based upon close communication, so the information left off the card arrives in any of the hundreds of conversations the developer has with the user. It is not that information is lost, but information transfer is moved from the writing to the speaking.
I like working at 4 bits of precision..... well, like is too strong a word, but I oblige myself to do it anyway, periodically. At 4 bits of precision I regularly turn up new requirements or new issues that never got mentioned in the user discussions I had had up until then.
So that already tells you why a 2-bit Use Case is more accessible than a 4-bit Use Case. Which would you rather write - a paragraph about the typical case, or all the failure handling scenarios. A business person will be able to do the User Story without special training and quickly, and the rest shifts into conversation. That shift similarly shifts the balance of power, as Kent says. I agree with his discussion of balance of power, even though I write 4-bit use cases and teach others also. -- AlistairCockburn
Come clean, Alistair. I know you like to use analogies, but you came up with this bit/precision analogy so that you could refer to a User Story as a 2-bit Use Case , right?
I couldn't resist the coincidence and I hope to start a fad. However, I defined project deliverables in bits of precision in early 1996. The online version is at http://members.aol.com/acockburn/papers/precisio.htm. In case you care, a class' name & responsibility statement make the first bit of precision for a class definition, and instance variables and methods are at bit 3 (name alone is not meaningful), so that puts CRC cards and UML class diagrams on the same line at different places, and also tells you something about class design. -- AlistairCockburn
A user story is very simple and is written by the customer. It's incomplete, possibly inaccurate, and doesn't handle exceptional cases because not a lot of effort is expended making sure it's correct. During development, it serves as a reminder and a starting point for additional discussions with the customer about the full extent of his needs.
A use case is more complex and is written by the developer in cooperation with the customer. It attempts to be complete, accurate, and handle all possible cases. A lot of effort it expended to make sure it's correct. During development, it's intended to be able to answer any developer questions about customer requirements so that developers may proceed without having to track down the customer.
My biased opinion is that user stories work better in any case that the customer is readily available. In my opinion, the use-case approach is wasteful since it tries to anticipate the questions that need to be answered, and that's naturally going to result a few questions being missed and a few more being researched unnecessarily. On the other hand, if the customer isn't immediately available, then the use case approach is probably better since it avoids the overhead of customer latency most of the time. -- JimLittle
If a UseCase and a UserStory represent the same thing, what is it that makes the one accessible and the other not?
Why can't iterative review be used with Use Cases? Is it that the focus is different or something? -- PeterMerel
Maybe it is easier to get users to write down what they need on a card in a few paragraphs than it is to get them to see the difference between uses and extends. -- PeteMcBreen
From the few examples of a User Story that I have seen, the big difference is in the level of precision. A Use Case is very precise and attempts to completely formalize all of the requirements relating to a particular interaction with the system. A User Story gives a specific example of what the results of the interaction should be. Being a specific, concrete example, it is more accessible than the more abstract formats that are often used for a Use Case. Having the Users involved in the development allows the developers to resolve the formal details later on in the development process.
I understand a UserStory is very quick to develop, whereas using a relatively formal UseCaseTemplate my experience has been that it can take two or three days to fully specify all of the Use Case detail.
It is all about how people use use cases. I've seen many people use use cases in a very formalized manner. Kent does his UserStories in a much more approachable manner. I do use cases the way Kent does User Stories. I call them use cases to better communicate with other developers and to influence them to use a more lightweight approach. -- MartinFowler
Interesting. Compare these quotes, the first from KentBeck, the second unreliably identified ...
I think I can now adequately say what a user story is or can be, and how to use it I've tried my descriptions in front of both Kent and Ron but I am sure that I can never get both Kent and Ron to accept both the description and its limitations.
I think that is because one of Kent's intentions for UserStory is that it not be too tightly defined, that it can morph with the need of the moment. Ergo, my (or anyone's) effort to bind it with a definition is self-contradictory. -- AlistairCockburn
WyCash used sometimes longish noun phrases in place of UserStories. They weren't even complete sentences. These were called ImpliedRequirements? in Episodes. Like UserStories, they were just labels that two groups could use to refer to future collaborative work. -- WardCunningham
I was wondering if the difference between User Story and Use Case is not just the title you give to it. I think the main difference is more the way you write either one of them. You can write a Use Case the User Story way and vice versa. p.s. is this still used? -- Boris Maltha B.O.Maltha@store-it.org
As far as I can tell, a UseCase and a UserStory have next to nothing in common. About as different as you can get for having names so similar. Should be called Abdefind and Zytyopy to make that clearer. -- AlistairCockburn
Does this mean that you come back on your conclusion User Story = 2-bit Use Case? -- Boris Maltha
Might be. Depends so heavily on what one writes in the story. At a general level, I find that comparing the two illuminates neither, nor does it lead a person to do better at either than if they'd never heard of the other. I compare user stories to either features or use case briefs, but I still hear of people creating user stories that are different to either. Very confusing to me. Try UserStory = "something that demands developer time". -- AlistairCockburn
A statement of the obvious, both UseCases and UserStories and advertised as a requirement gathering technique, that's why we compare them, my problem with most books on systems requirement it that it leaves many details out, which eventually becomes misleading, for example, I don't think you can write down UseCases during an interview, because of the level of detail and effort UseCases require, and I do think many will attempt to use UserStories as an interview documentation technique, which I am not sure is optimal, but maybe feasible, most what developer analyst [?] want is a practical and easy way to document an interview, UseCases are not meant to document interview, neither are UserStories, they are meant as a higher level of precision, which require more than reflective thinking, I think recording an interview is the optimal way, take the tape to your office listen to it many types, write down the UseCases or UserStories according to their standard, and move up or down until you have code, or you can jump directly to the code level if you some kind of genius, problem is we can not alway record interview, and it's a long way from requirement to code do jump, take the leader, document every step you make, taxonomize everything. -- AliMotaz
[EditHint - the preceding paragraph needs conversion to English.]
I think of a UserStory as a token that stands in for a conversation whose purpose is roughly equivalent to that of a UseCase. The content of a UserStory is often an abbreviated version of the main success scenario of a UseCase, but it doesn't have to be. -- PhilGoodwin
I think the difference between using nothing and using either UserStory or UseCase is more important than the difference between UserStory and UseCase. As long as one is used in a good way, the final product will be better than when nothing is used. -- BorisMaltha?
Thank you for reminding us of that. You are so correct. -- AlistairCockburn
the UseCase wiki is operational: http://www.usecases.org/cgi-bin/wiki.pl?UseCasesRecentChanges
I just noticed two cases, in which I suggested UserStories for one, and UseCases for the other. Written up at http://www.usecases.org/cgi-bin/wiki.pl?CombiningUseCasesAndXpStories -- AlistairCockburn
It occurs to me that an important difference between UserStory and UseCase is that UseCase discusses interactions with a system, and so must in some way be prescribing system behaviour, whereas UserStory doesn't and needn't.
This is important for me because one thing that we get quite hung up about with my current consultancy work is the separation between requirement and solution.
The client specifies a requirement, the supplier proposes a solution. The client talks in terms of user stories, such as "process a child benefit claim", rather than UseCases such as "enter child benefit data". One assumes that the given story will result in the given use case but the latter only comes about as a result of a first level of analysis which the supplier produces in response to the requirements.
"Enter child benefit data" is a step, not a use case. The use case is "process a child benefit claim". If the granularity is right, the name (and actor goal) of a user story should be the same as the corresponding use case. A lot of the discussion of both these topics confuse user stories and use cases with functions or features. Neither should go deeper than the external design of the product. If anything in a user story or use case describes something some user won't see, you've gone beyond requirements gathering and moved prematurely into development.
IOW, client produces user stories, supplier answers with use cases.
These use cases are not normally presented as such, of course, but rather appear in documents which show screen layouts and so on. I personally can't see the use of presenting UseCase scenarios to a customer in the style you see in tools like Rose, for example.
As I see it - if a User Story captures the goal of a requirement, a Use Case can capture the details of that requirement. Remember a Use Case and Use Case Model also elicit the Actors, which in essence determines who can "read" the User Story. I believe that Use Cases and User Stories are compatible and can provide supporting logical views of the same requirements. -- MauriceLynch?
I came to believe today that maybe the difference between a UseCase and a UserStory is that a UserStory is essentially a token for a later creation of a UseCase. Think of it like lazy evaluation in some programming languages or even YagNi for requirements gathering. It seems like the basic idea is that you want to get a good enough idea of you as a developer for what you are being asked to do so that you are able to create a meaningful estimate. The UseCase then servers as a promise of conversation for more complete specification at a later time (or maybe never because it could be decided that the story on the index card is not needed). That later conversation could easily have as output a UseCase that is written down or just the knowledge that is transferred from one person (the customer) to another (the developer).
A perspective...
In the beginning, there was the functional specification, and it was good. The spec wants to be complete and indisputable, a lawyerly description of what the system does. In the absence of other communication between user and developer, it is a necessary device. Close enough to the code as to be nearly unambiguous, but so nearly as large and complex. Yet the spec cannot be executed, and hence tested, except in the mind of the reader. It can be written by only a few, yet must be read, understood by and and approved by those that can or do not. The spec does not trust the developer to listen well and do the right thing.
Enter the smaller, more accessible use case. Essential flow and behavior are specified; irrelevant detail is left to the discretion of the trusted developer. The use case can be written by a wider variety of people, user types included, But discipline is still required. Alternative and error flows must be accounted for. Consistency is necessary, or the case cannot be built. And completeness helps, because at some point, the listening stops and the case is built, and if it's not in the use case, you're not necessarily going to get it. When you write a use case, you are not just expressing requirement, you are doing design.
Enter the even smaller and more accessible user story. No design here. Just a decomposition of requirements into units with individual value, cost and risk. Stories listen better than use cases, because they don't commit to any particular design. -- PerisBrodsky
Trust but verify. Contract law doesn't exist for no reason. Being specific is to verify understanding. Trust has nothing to do with it.
Trust but verify, absolutely. User stories alone are inadequate for the collection of requirements for a software product. This is why Agile prescribes customer collaboration which can be seen as the demonstration of working testing software to the customer for review on a regular interval (the end of sprint demo from Scrum). This continuous collection of feedback nullifies the need to "get it right the first time" and focuses more simply on getting it right. Use Cases may be advantageous as design aids, but they will not prevent the litigious from litigating. In the use of Use Cases, one must be careful to not let them take the place of conversation with the customer about the requirements of the system. -- RobertStackhouse?
My take on this.
I invented and developed Pacemaker® - The pocketsize DJ system http://pacemaker.net. It is a complete disc jockey system, packing two decks and a mixer into something in the size of an iPod (actually a little bit bigger, more like a Sony PSP) . Normally a DJ system is the size of an office desk so the main challenge was to create a new interface. I new about UML and had been using it with great success to develop a control system for a Milking robot, both hardware and software.
Now I have read Alistair Cockburns recommendations on how to use use cases and he clearly states that it should not “specify user interface design”. I do agree with this but, the Pacemaker® user interface was successfully developed with great help of use cases. The use cases did not capture all of the requirements for the user interface and interaction, but enough of it. The use cases then became the foundation for the entire team of programmers, industrial designers and everyone else involved in the development of the product.
So what has this got to do with user stories and use cases? Well I have now started a new project, a web project. And since use cases were so successfully used in the Pacemaker® project we choose to use it once again. And then our scrum master ran into user stories and he liked them so I looked into the difference and ended up here.
This has been said before in the above discussion, but I will say it again and this is my take on user stories vs. use cases:
'User stories capture functionality and output of a system.' 'Use cases capture the functionality, interaction as well as pre- and post conditions.'
For me this can roughly be translated into that user stories are the name, pre- and post conditions of a use case.
What I really miss in the user stories is the ability to capture the fundamental user interaction, which is the fundamental user interface. And today more than ever, it is all about the user interface and interaction, so I think it is a very important aspect to keep.
Then the aim with user stories according to Kent is that he wanted the business department to get involved and feel for the requirements. A very important thing!
But I think that can be done with use cases, especially given the arrows and bubble view that they have. We used that view a lot and the great benefit with it was that the business people loved it. It was the perfect level for them. They do not want to read boring text. -- Jonas Norberg
UseCasesAreUserStoriesWithAcceptanceTests
Another voice: I think business people, and IT folks, can get hung up on the templates for each. Neither are magic. The value comes out of the modeling which should be a pre-requisite for "doing" either one. In my humble opinion, they are both visionary starting spots and nothing more. I'm fine with the Essential Use Case that Alistair recommends combined with the stickman representation as step one, but generally, using both User Stories & Use Cases seems to confuse things. Honestly, using a bunch of stickies for "stories" then grouping them into "EPICS" and removing duplicates seems to be an even better starting point. Call your EPIC, a Use Case, if you like, and work in both directions from there - to the Essential Use Case and to the Acceptance Criteria. There are only 3 things that are important:
1. Knowing what the Biz Intention is, all their rules
2. Understanding the Results desired in all scenarios
3. Having the work grouped in comprehensible and testable lots.
See my two blog posts on this topic. http://web.me.com/seabreezes1/Karen_Spencer/Blog/Entries/2010/10/21_Use_Cases_%26_User_Stories.html
Karen Favazza Spencer
October 30, 2010
Another perspective....
User stories are more effort based and less based on levels of precision. The effort to complete a user story is typically one iteration or less. That is at least the goal. Looking at it this way, if a user story is estimated to go beyond a single iteration, it is not a good user story and must be broken down. As user stories are broken, certain portions may be deemed as lower priority and pushed to later releases. Use Cases are not handled this way and aren't structured in a way that will *easily* facilitate planning and prioritization. With use cases, people skilled in writing use cases continue to combine flows and requirements with less regard for the planning and prioritization (and ultimately development) and with more regard for attempting to create comprehensive system documentation. Documentation is needed, but there is overhead in breaking use cases back down into workable chunks that can actually be developed, whereas this is "built in" with user stories. GregPhillips?
EditText of this page
(last edited November 10, 2014)
or FindPage with title or text search