User stories – when the harm is greater than the benefit
User Story 1: As a user, I would like to contact customer support via chat to clarify my question.
User Story 2: As a buyer, I would like to be able to view my previous orders in order to make a new purchase decision.
Abstracted, this results in the following formula for building user stories:
As a [role], I want [function] to [benefit].
User stories of this kind, however, often harbour three major problems that can significantly hinder product development or manoeuvre it into a dead end.
- Problem 1: The context and/or the concrete use case are ignored.
- Problem 2: Meaningless personas are used for the use case.
- Problem 3: The function is directly linked to the result for the user.
In the following, I would like to shed light on what these problems can mean for your product development and why they should be avoided at all costs.
Problem 1: User stories that disregard context and the specific use case
Let’s take another look at the initial examples:
User Story 1: As a user, I want to contact customer support via chat to clarify my question.
User Story 2: As a buyer, I would like to be referred to my previous purchases in order to make a new purchase decision.
User Story 1 leaves us completely in the dark as to which user we are dealing with. User Story 2 supposedly does better, but again no specific use case or context is named. Is it a regular or old customer? Does he always buy the same product or does he want to find something new, compare offers or complain about goods?
As a Product Owner, you should always question the formulation “users want”. It is always questionable if the user story does not describe in detail which user is meant. Then it disguises the fact that nothing is known about the user. In such a case, there is a need for clarification.
However, it is always worth asking: Is the role of the user at all necessary for this user story or is the description of a concrete use case sufficient? Quite often you will be able to help yourself in this way. For example, User Story 1 can be formulated more sensibly:
“When a website visitor contacts customer support, he or she wants…”.
One thing is for sure: putting forward an empty role description such as “user” or “buyer” will lead to a lack of common understanding for the use case in the development process.
Problem 2: User stories based on personas
First of all, personas undoubtedly fulfil an important function within agile product development. They enable the team to empathise with the users of the product and help decisively, for example, in the creation of a suitable user interface.
With regard to user stories, however, personas are out of place: they usually do not help us to understand the context and causality of a concrete use case.
Let’s assume a shopper has bought a muesli bar. For our shop, the user persona “John” is defined as follows:
John
- is male, 42 years old,
- unmarried and lives in Berlin,
- has a degree in psychology and works in an agency,
- is lactose-intolerant,
- loves snacks on the go and eats one bar a day,
- has a dog,
- is very sporty and leads an active lifestyle,
- orders clothes and shoes online and
- eats sushi regularly.
Why did John buy the muesli bar? To satisfy his hunger on the go.
The causality of the purchase situation “I’m on the road, feel hungry and have to decide in a few seconds on a purchase that will fill me up for the next hour” results from the concrete situation, but cannot be justified with any of the other attributes assigned to John within the persona.
In the same way, this purchase decision would have resulted for the completely differently defined persona “Maria” (56 years old, married, teacher, rather unathletic, lives in Ulm).
So it is not the existing personas that are useful for this user story, but here too the description of the concrete case helps:
“When I’m out and about, I’m hungry and want to buy something quickly that will fill me up for an hour, then I want …”
Problem 3: The function is linked to the result for the user
Let’s link the function and the result for the user into one unit as in our example:
User Story 1: As a user, I want to contact the customer support in the chat to clarify my question.
So: “The chat with the customer support clarifies the user question”, then we run the risk of manoeuvring ourselves into a dead end.
We have to consider: more than half of the features of a product eventually turn out to be a flop. If the user story now defines a feature that is linked to the benefit for the user, it becomes difficult or perhaps impossible to find out afterwards why this implementation failed. The linkage makes it impossible to recognise what was wrong in the first place.
Was it the implementation or were the assumptions about value wrong?
And it goes even further: the fact that user stories that are inappropriately linked and too focused on concrete features can have a negative impact on agile product development as a whole is shown in the concluding section.
User stories that prevent innovative product development
It can be seen that, in addition to the problems caused by a user concept that is empty of content and faulty couplings within the user stories, the stiffening on concrete product functions slows down or prevents innovative product development.
Let’s look at the schematised user story again:
As a [role], I want [function] to [benefit].
This format dictates functionality to developers. Product Owners who use it degrade developers to purely executive team members. They hinder them from taking initiative and responsibility for solving a problem.
In such a constellation, the Product Owner often acts like a kind of “mini-CEO” of the product. This description of the role of the Product Owner is questionable and it should be questioned: Is the Product Owner the one who ultimately decides everything? From the Scrum Guide‘s point of view, this would not only be wrong, but would also hinder the innovation capacity of the whole company.
Product Owners are rather Product Leaders. As leaders, they lead by giving freedom so that the developers can contribute creatively in order to find the solution that really inspires users.
If you want to be a product leader, you should never write user stories that describe an already known, learned user function. Instead, they should tell their team about a user’s motivation or goal.
So it’s not, “As a user, I want to search for job opportunities on the site.”
But rather: “I would like to receive a job offer that is suitable for me.”
Or, “I want to get in touch with companies that are looking for reinforcements (and know if I’m eligible for the company).”
Typically, users will not describe their own desires, motivations or goals in this way, but suggest solutions they already know. Steve Jobs recognised this early on and it was summed up in his biography by Walter Isaacson¹:
“Some people say, ‘Give the customers what they want.’ But that’s not my approach. Our job is to find out what they will want in the future before they ever do. I think Henry Ford once said, ‘If I had asked the customers what they wanted, they would have told me: a faster horse!’ People don’t know what they want until you show it to them. That’s why I never rely on market research. Our job is to read things that are not yet on paper.”
With this in mind, part of the Product Owner’s job is to be aware of this fact and focus less on known features and more on a product vision. Then turning this into user stories that enable the whole team to develop a shared understanding from which innovative solutions can emerge is the challenge that makes the product leader so important.
Notes:
[1] Steve Jobs: The Apple founder’s authorised biography
If you are interested in Scrum.org trainings with Simon Flossmann, e.g. Professional Product Owner™ (Advanced), Professional Scrum Master™ (I+II) or Agile Leadership™ (Essential+Evidence Based Management), feel free to check out trainings from Colenet.de.
If you like the post or want to discuss it, feel free to share it with your network.
Simon Flossmann has published two more posts on the t2informatik Blog:
From feature roadmap to outcome roadmap
Eliminating dependencies in Scrum
Simon Flossmann
Simon Flossmann is an experienced Scrum practitioner and has worked from start-ups to large corporations in a variety of industries. As a Professional Scrum Trainer at Scrum.org, he helps Scrum Masters, Product Owners and Agile Leaders implement Scrum to work more effectively.
Because of his deep knowledge and experience working with multiple Scrum teams, Simon Flossmann is one of the two stewards of the Scaled Professional Scrum training, helping to evolve the course and maintain the integrity of Ken Schwaber’s vision on Scrum.