You Do Not Need User Stories
If all you have is a hammer, everything looks like a nail.
Most agile development teams describe functionality with User Stories. Agile and User Stories go together like peas and carrots. Create an epic and split it up in User Stories. Sprinkle it with Story Points and acceptance criteria on top, and now you are good to go.
Teams apply User Stories without considering if they are actually the best tool for the job. If all you have is a hammer, everything looks like a nail.
The foundation of a User Story is the persona: an imaginary representation of a type of user. Personas are described using attributes that are simple to quantify, such as age, sex or race.
Just because attributes are easy to measure, does not make them matter.
When Customer Attributes Fail
A big fast food company was performing research to increase milkshake sales. Their research started by focusing on the different characteristics of customers. The researchers performed many experiments based on customer attributes to improve sales. None of these experiments resulted in selling more milkshakes.
The researchers shifted their attention from the customer to the milkshake. The company asked their customers the simple question: “What is the job you hire a milkshake for?”
What they discovered using this approach was surprising. Around half of all milkshakes where bought early in the morning by commuters who traveled by car. Why did they hire a milkshake for the job, and not bananas, bagels or Snickers?
A banana is easy to eat in a car, but did not stave off hunger till 10 AM in the morning. A bagel with cream cheese would keep you full long enough. But bagels are dry and it is difficult (and dangerous!) to add cream cheese while driving. A Snickers bar seems the perfect alternative, but does not last long enough to keep you occupied in the car.
A milkshake keeps you full till 10 o’clock. It is easy to consume in a car and keeps you occupied during the commute. This is the job a milkshake was hired to do. The company adjusted the milkshake to make it perform this job even better. The milkshake sales suddenly increased.
The job of the milkshake is what matters, not the characteristics of the customer.
Shortcomings Of User Stories
What if the problem your product solves, defines the product better than customer attributes? User Stories are then the wrong tool for the job.
User stories have the following simple format:
As a <Persona>, I want <Action>, so that I <Expected outcome>
If the only thing your users have in common is the job to be done with the product, using personas is dangerous. It will only introduce implicit assumptions and ambiguity to your development team. The persona generates noise without providing insight. Attributes are not what makes the difference.
The action produces the expected outcome for the user. But users are not motivated by actions. How do we actually know this is the action the user wants to perform?
Focusing On The Job To Be Done: Job Stories
Job stories have the following format:
When I am in <Situation>, I want to <Motivation>, so that I can <Expected Outcome>.
The situation describes the context of the user. Imagine the following situations.
- You are busy painting a wall and run out of paint.
- You are busy painting walls in the kitchen and are almost running out of paint. Tomorrow your new kitchen arrives and if you do not get new paint soon you will not be able to finish.
The context of the situation helps designing the best solution. In the first situation, a solution would be to reserve your paint online and pick it up in the store. No hurry necessary. In the second situation, you want to order online to get the paint delivered within 1 hour. This means you can keep on working while the paint is en route and finish on time.
The motivation covers the push and pull of the desired situation. What is attractive about the solution that pulls the customer? What fears and anxieties may be triggered.
For the second situation:
Motivation:
I want to get more paint as soon as possible.
Push and pull forces:
I am annoyed by the fact I am almost out of paint.
How can I be sure they deliver exactly the same paint and it is in stock?
I am worried they will not deliver quickly enough.
I want to be in control and pick it up myself.
I will not be able to finish in time if I pick up the paint myself.
Taking into account the situation and motivation allows to design more persuasive and better solutions. The better your understanding of both, the better you can shape your solution to fit the needs of your customer.
Hire Job Stories To Establish Causality Better
Using Job Stories you can design better solutions that take into account the hopes and fears of users. It allows considering their context, instead of implying it based on attributes. Job Stories help getting to the bottom of the Jobs-to-be-Done. What is the job we want to hire this product for?
The next time you default to writing yet another User Story, consider if you would be served better by starting with a Job Story instead.
If you want to know more about Job Stories, I can really recommend following Alan Klement. He is a thought leader on the subject of Job Stories and his articles are extremely insightful.
You Do Not Need User Stories was originally published at mdalmijn.com
