This is a free translation of Courtney’s original blog post
Boost Agile (Use cases vs user Stories in Agile
Development,
18 de January de 2012, www.boost.co.nz).
TL;DR - User Stories are not the same thing as use cases. By itself, the user Stories don’t provide the details the team needs to do their job. The Scrum process allows these details to emerge organically (largely), removing the need to write use cases.
As user Stories are the same thing as use cases?
When we are doing our workshop "Writing Great Agile User Stories", I often get the question "But then, the user Stories are the same as use cases?". It is usually a business analyst who asks this question; they are used to working with use cases, and wonder where use cases fit into a Scrum project and whether they are replaced by a user story.
Searching the web, there is a consensus that use cases and user Stories are not interchangeable:
My standard answer is that user Stories are centered on the result and benefit of the thing being described, while use cases are more granular, and describe how the system will act. And then I say "Be patient - soon everything will be clear". But I think it’s time to deepen on this subject.
Use cases and user Stories
Let’s start with some definitions.
One user story is a short description of something your customers will do when they sign in to your website or use your application/software, focused on the value or outcome they will get when they do it. They are written from the point of view of the person using the website or application, and in a language that their customers would use.
One user story is commonly written in the format canonized by Mike Cohn: As an [actor] I want [action] so that [result] (in the English original, As an [actor] I want [action] so that [Achievement]). So for example: As a Flickr member, I want to set different levels of privacy for my photos so that I can control who sees each of my photos.
A use case is a description of a set of interactions between a system and one or more actors (where "actor" may be people or other systems: for example, both online buyers and Pagseguro may be actors). They are usually created as documents, and usually include the following type of information:
- Title of the use case
- Rational analysis/description/objective
- Actor/user
- Preconditions (things that need to have already occurred in the system)
- Standard script or main success scenario (which commonly happens, described as a series of steps)
- Alternative routes or extensions (variations of the above cases or exceptional cases)
- Post-conditions (what the system will have done at the end of the steps)
In a quick glance, use cases seem a much better way to write requirements than user Stories. How will a team be able to implement something as insubstantial as "As a Flickr member, I want to set different levels of privacy for my photos so that I can control who sees each of my photos"? Do you not need some detailed use cases to detail the system requirements? And it’s at this point that usually someone at the workshop asks the fateful question.
The writing of use cases to detail user Stories in Agile projects is nothing new (see here and here). But it’s clear, as we progress in the workshop, that user Stories are just the beginning of the process of understanding what the team is producing, and that, at the end of the course, covers everything that a use case would have informed, but in an organic way.
Acceptance criteria
User Stories are not only unique phrases. The product Owner also writes acceptance criteria, defining the limits of a user story and are used to confirm when it is complete and functioning as intended. For example, if this is your user story "As a conference attendee, I want to be able to register online so I can do it quickly and reduce the paperwork, "the acceptance criteria could include:
- A user cannot submit a form without completing all required fields.
- The form information is stored in a record database.
- The spam protection is working.
- Payment can be made via credit card.
- A confirmation email is sent to the user after submitting the form.
The writing of the acceptance criteria is the first step towards producing the details of your user story.
Sprints Planning Meetings
In meetings for planning a sprint, the product Owner presents the user Stories from the top of your backlog (that is, the highest priority functions) and the team commits to the Stories that will complete in sprint.
According to the product Owner presents the Stories, the team asks questions to help in the detailed understanding of them and the acceptance criteria. Assumptions are quickly confirmed or corrected, and any ambiguity about the requirements begins to fade.
This process of eliminating assumptions and ambiguity continues as the team estimates Stories (if five people on the same team qualify one story as 2 and one person classifies it as 5, so there are probably some questions that need to be answered). And it’s repeated as the team writes the individual tasks of each story.
Standups
We have been lucky with our Scrum projects because our product Owners have committed themselves to the meetings of standup with the teams. This is another opportunity for the team to ask questions and also help the product Owner to be aware of the constraints, problems and opportunities that present themselves as the development of story progresses.
Wireframing
I do wireframes of some of our projects, usually starting by talking with product Owner on the story and, some truths, starting from some drafts on paper or in the frame. I turn these drafts into wireframes, when some quick interactions with the product Owner as we ask questions, we get feedback from other people and (when possible) we get space to do one or the other test with the user using the wireframe.
More recently I have begun to review the wireframes with designers and developers working on Stories. This helps to point out any issues that they may have, as well as restrictions that I may not yet be aware of. After the approval of wireframes for product Owner, i pass information again to designers and developers if necessary.
Design and development
Although most of the details were dealt with during the creation of the wireframes, something else may arise during this stage and often other questions arise for the product Owner about how exactly he or she wants the backend the system behaves. A peer programming is useful here, because two pairs of eyes on a piece of functionality means there will be even more questions and clarifications.
None user story is submitted for acceptance by product Owner until the acceptance criteria are met and "definition of conclusion" be achieved.
Overall
This may all sound like a time-consuming process. But it’s really all a Scrum team does throughout the day. Instead of one person only working on use cases, the whole team works together to make emerge and to satisfy all requirements. The product Owner may refine the original acceptance criteria in response to new information obtained during the progress of user Stories.
And finally, in conclusion
There are exceptions, of course - and there are times when the advanced research provided by use cases is important (I have a post about this in the oven). But my advice would be: don’t start writing use cases until your team specifically asks for them. And if your team doesn’t ask for them, spend some time on an evaluation retrospective of the "what" they are not getting from the current process (for example: are the acceptance criteria clear? ; the product Owner is unavailable? ; are we working with bad documentation from another system? etc). Only then decide, along with the team, how to fix the root of the problem.