By Nathan Donaldson
Tags: Agile
User stories aren’t use cases. By themselves, user stories don’t provide the details the team needs to do their work. The Scrum process enables this detail to emerge organically (largely), removing the need to write use cases. Find out how.
When running our workshops, I’m frequently asked “So – are user stories the same as use cases?”. Often it’s a business analyst who asks the question; they’re accustomed to working with use cases, and are wondering where use cases fit in a Scrum project, and if they’re replaced by a user story.
Looking around the web, there’s consensus that use cases and user stories are not interchangeable:
My standard answer is that user stories are centred on the result and the benefit of the thing you’re describing, whereas use cases are more granular, and describe how your system will act. And then I say “Just bear with me – it will all be clear in soon”. But I thought it was time to dig further down into this.
Let’s start with some definitions.
A user story is a short description of something that your customer will do when they come to your website or use your application/software, focused on the value or result they get from doing this thing. They are written from the point of view of a person using your website or application, and written in the language that your customers would use.
A user story is usually written using the format canonised by Mike Cohn: As an [actor] I want [action] so that [achievement]. So, for example: As a Flickr member, I want to set different privacy levels on my photos, so I can control who sees which of my photos.
A use case is a description of a set of interactions between a system and and one or more actors (where ‘actor’ can be people, or other systems: for example, both online shoppers and PayPal can be actors). They are usually created as documents, and generally include this kind of information:
At first blush, use cases look like a much better way of writing requirements than user stories. How will a team be able to implement something as wafty as: As a Flickr member, I want to set different privacy levels on my photos, so I can control who sees which of my photos? Won’t it take some rigorous use cases to detail the requirements for the system? And that’s usually the point when someone in the workshop asks that question.
Writing use cases to flesh out user stories in Agile projects is certainly not unheard of (see this Breathingtech post, and the Use Case Blog). But it becomes clear as we move through the workshop that user stories are just the start of a process of understanding what the team is making. By the end of this process, you’ve covered off everything a use case would have told you, but in an organic manner.
User stories aren’t just single sentence affairs. The product owner also writes acceptance criteria, which define the boundaries of a user story, and are used to confirm when a story is completed and working 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 register quickly and cut down on paperwork, the acceptance criteria could include:
Writing the acceptance criteria is the first step of fleshing out the details of your user story.
In the sprint planning meeting, the product owner presents the user stories from the top of their product backlog (i.e. their highest priority features) and the team commits to the stories they will complete in the sprint.
As the product owner presents the stories, the team will ask questions to further clarify the user story and the acceptance criteria. You’ll be able to quickly confirm or correct assumptions, and start to get rid of any ambiguity about the requirements.
The team further clarify assumptions and ambiguities as they estimate the stories (if five people on the team rates a story as a 2, and one person rates it as a 5, there’s probably some questions that need answering). And this clarification process continues as they write the individual tasks for each story.
We’ve been fortunate in our Scrum projects, in that our product owners generally commit to attend the team stand-up. This is another chance for the team to ask questions, and also to make the product owner aware of restrictions, issues and opportunities are appearing as the story progresses.
I do the wireframing for some of our projects, and usually I start by talking to the product owner about the story, and sometimes making some paper or whiteboard sketches. I turn these into wireframes and then there’s normally a couple of quick iterations with the product owner as we ask each other questions, get feedback from other people, and hopefully squeeze in some user testing.
More recently, I’ve started reviewing the draft wireframes with the designers and developers working on the story. This helps flag up any questions they have, or restrictions I might not have been aware of. After the wireframes are approved by the product owner, I’ll brief the designers and developers again if needed.
Although most of the details have been thrashed out during the wireframing more can crop up at this stage, and there are often more questions for the product owner about exactly how they want the backend of the system to behave. Pair programming is useful here, because two sets of eyes on a piece of functionality mean yet more questions and clarifications.
No user story is submitted for acceptance by the product owner until the acceptance criteria are satisfied and the definition of done is met. You can learn more about the difference between the definition of done and acceptance criteria here.
This might sound like a lengthy process. In reality, it’s just what a Scrum team does all day. Rather than one person labouring over the use cases, the team works together to surface and satisfy all the requirements. The product owner can refine the original acceptance criteria in response to new information throughout a user story’s progress.
There are exceptions, of course – and there are times when the upfront research needed for use cases is important (I’ve got a blog post brewing on this). But my advice would be: don’t start writing use cases until your team specifically asks for them. And if your team does ask for them, spend some time in a retrospective digging into what they’re not getting from your current processes (for example – are the acceptance criteria unclear; is the product owner unavailable; are you working with shitty documentation for another system). Then decide as a team how to fix the root problem.
Starting a new project? Check out our Agile Project Kick-off Kit to learn about user story mapping and prioritising user stories during project discovery.
Advantages of user stories for requirements – Mike Cohn
Requirements 101: User stories vs use cases – Andrew Stellman
Business analysts and Scrum – Boost blog
