Which one suits your project better: Use case or user story?
Do you know how many results you get when you search “UX” on Google? (In private/incognito mode) 234 million results appear. In the UX world, where there is so much content; it is normal to have mistakes and accidents. However, some of these accidents, if not careful and no action is taken, could increase the risk of casualties among team members. Let’s take a look at one of the most common areas of “accident” and answer one of the most fatal questions: Should we write Use Cases or User Stories in the UX documentation? (If you say both, don’t read the rest of the article at all; take a short walk, come back and give it another try.)
Since the “Agile” hurricane struck Turkey, the debate over writing Use Case and User Story has been flaring up among the enthusiasts. If the main concern of the Agile methodology could be interpreted as “Taking the simplest and the most effective steps first and delaying the rest of the concerns until the product creation phase” writing both the Use Case and the User Story in a UX project, creates an antithesis to this statement.
You ask why? Let’s answer why by examining in detail the key differences, the risks, and the approaches that emerge when using Use Case and User Story.
Use Case
Use Case is the name given to an end-to-end interaction sequence that takes place between an actor and the system, creating a value observable by the actor.
So you may be thinking “This is a wonderful definition, however, isn’t it like a quantum physics term definition? It says so much but means so little” then you are not alone. When you place the above definition and the stick figures together (just type Use Case on Google and you will know what I mean); then you would most likely end up with an unwanted documentation format which will never be used again.
I think it would be more practical to continue with an example:
The actor does something.
The system does something else.
The actor does something other than that.
The system does something totally different.
For those who say “Please, show me visually.” The following example for Use Case diagram is for you.
Here are a bunch of interactions. So, is this it? Is this the Use Case? No.
Finally, for these series of interactions to form an end-to-end flow (the main flow), we need “alternative flows” for the exceptional circumstances and alternative steps.
For someone else, such as a designer or a developer, to work efficiently after examining the User Case; the main and alternative flows about the activities framed by the User Case must be thought thoroughly. This thinking practice also requires you to have a good command of the rules that determine how the actor interacts with the system in the Use Case, which rights those rules give to the actor in exceptional circumstances, and how they direct the actor.
In other words, the BDUF – Big Design Up Front, which is opposed by Agile from the beginning, becomes mandatory. Rightfully, for the Use Case production “Let me think of everything, plan, detail and then start production.” becomes inevitable.
Weren’t we supposed to be Agile?
User Story
The key to writing a User Story is avoiding details in the beginning stages of the project; creating a working environment where details can be added to the project in a timely manner and as needed.
Unlike Use Case, User Story samples are created with much simpler reasoning:
As a <user>, I can <indicate folders not to backup> so that <my backup drive isn’t filled up with things I don’t need to be saved>.
In fact, as the key approach summarizes, the User Stories were born as a reaction to extreme elaboration. This is exactly why they are called anti-BDUF. When Kent Beck came up with the concept of eXtreme Programming (XP), he positioned the User Story as a point of support for this iterative and progressive production approach and pointed to the true Agile methodology.
Mike Cohn took the issue another step, wrote a book called “User Story Applied” and created a remarkably rich bibliography on the use of User Story in Agile projects.
Next, Jeff Patton introduced the Story Mapping technique to keep User Stories from drowning in the functional depth of a product. This effort became a method of positioning a User Story, which may be seen as very simple, in relation to the bigger story and showing how we can connect it to other (simple!) User Stories.
I would also like to share the following graph summarizing the position of User Story in Agile:
As can be seen from the examples, there are three prominent concepts in the User Story creation process:
We answer the question: What type of user are we writing this story about?
We identify the activity, seen as a need in the story.
We clearly demonstrate the user benefit that emerges as a result of this story so that we can review it in our prioritization work.
The position of the User Story within the value chain, in the axis of the business objectives of the product; depends on the clear manifestation of these 3 steps.
Although I would like to continue with the “Acceptance Criteria” that defines the acceptance status of the User Stories, Epics which is the next level above User Stories, and the “3C”s of Mike Cohn’s User Stories: Card, Conversation and Confirmation; I put an end to the User Story explanation and recommend you to have a look at the reading list at the end of my article.
The main difference between Use Case and User Story
The key difference between these two concepts is timing. The product design environment can constantly change because of business objectives, product characteristics and the constraints of project time limits. If you are trying to develop a product in that environment at a time when response time is a sought after capability, you have two options. Trying to think of all details, making analysis from the start and then deciding if you will design or not, places User Story and Use Case on two opposite ends.
Use Case is the choice of “I define every detail from the start” people, and User Story on the other hand is the choice of “I only define the essential details needed at any given point” people.
User Story people tend to think that they can whenever necessary further elaborate the User Story and create other User stories associated with it, and acknowledges that even this User Story may become unnecessary in the future, and they may have no objections to remove it. Use Case people think differently. Essentially they because of their fear to deviate from the detailed analysis, tend to clash with change.
Can I use the Use Case instead of User Story in an Agile Project?
In theory, there is nothing against it. However, choosing Use Case in an Agile project forces the resolution of a gigantic dilemma which is the imposition of “monolithic” and “absolute acceptance/rejection” philosophy. There are two factors that build a barrier between fragmented and iterative creation. The first one is that in the Use Case Creation, both cause/benefit definition is usually ignored and secondly, the lack of necessary relationship to be established between the business objectives and the Use Case. The effort spent trying to solve many small issues from the start will produce some results. However the loyalty to such results during the production period will put a barrier to the effective use of time and neglect “recent developments” that could provide added value.
Which one to use?
I am a part of the generation whose projects do not continue as they were planned/agreed upon.
I’m a veteran who admires the Japanese way of working. When my plans completely fall apart in the middle of a project, instead of whining about it, I happily take full responsibility to do my best to solve the issues. Most likely “the man who died while keeping the project going” will be engraved on my tombstone.
If you’re trying to do business in a market where discipline is of utter most importance similar to a football player on the German national team, and if your sole capital is time; I suggest you choose User Story and the iterative approaches that come with it.
“I like the subject. You said there was a reading list?”
If you are interested in the topic, you can start reading the following in order:
- What is a user story?
- What is a use case?
- User Story writing techniques
- 3 Common User Story Mistakes
- A Day in the Life of a User Story
- A framework for modern User Stories
- Are User Stories and Use Cases at war?
- User Stories, Tech Debt and Defects