User Stories

Myth: The Product Backlog consists (exclusively) of User Stories
Variations:

• We need to find ways to formulate everything as a user story
• Fake Story Users

Follow-up myths:

• Technical User Story
• Developer Story
• User Personae
• Every item must be written in the Connextra Template
• The PO must learn to write proper User Stories
• It matters how well written a User Story is

Category: Backlog myths
Danger: High

The basis of the myth

It's actually difficult to pinpoint where the myth originated, but it's really wide spread.
Many people, including trainers and coaches, propagate the idea that you need to work with "User Stories".

Why is it a myth?

The Scrum guide doesn't even mention "User Stories". It only talks about "Product Backlog items". (PBI's). Even then, a PBI can be "everything that might be needed in the product". There is no specific hint to "users" or format. According to the Scrum rules, it's completely fine to dump a Detailed Specification Document or a sketch doodle into the Product Backlog.

The only constraint on a PBI is that when the team decides to work with it, it's "ready" - whatever that means in your team!

Assumption #1: Mandatory Format
The problem with any kind of mandatory format is that the formatting process consumes capacity - which may or may not be a valuable investment. Most certainly, it's not a valuable investment when we don't even know yet whether we are even going to build the stuff!


Assumption #2: It's all about users

Scrum nowhere prescribes that we only work on stuff that is relevant for a "user". Let's take, for example, a technical interface refactoring: That thing has no "users" aside from machines and it's a complete waste of time to think how to phrase a mandatory technical change from a user perspective. "As a customer, I want the system to convert the XML data I send to the system into JSON" - No! No, no. This is wrong on so many levels ... While the customer does care that their data gets processed, what's happening here something that the customer couldn't care less about.
Can you imagine Old Aunt Irma sitting in her rocking chair, telling you "Sweetie, I want my XML data processing to be converted to JSON?" - well, if you can't - then you know that this is not a real user story!


Assumption #3: Clarity 
Do "user stories" add clarity? Well - maybe. But only if they're real stories told by real users. And even then, they might actually obfuscate matters. Let's just think of "My computer doesn't work": That's a real user story. Even "Oh, I didn't realize that I didn't turn it on" is part of that story.
Now, you could rewrite this as "As a user, I want to be reminded when my computer is not turned on so that I remember to turn it on." - but is that really the thing you're going to work on?
Wouldn't "Power switch unintuitive", adding the real user's statements as details, be even clearer for developers?
In this case, a "user story format" is actually masking the activity and intended outcome by rewriting this stuff from an end user perspective.

Consequences

Waste

Teams and/or Product Owners investing time to turn stuff that's already clear into so-called "User Storys" is waste of time and effort. The purpose of refinement is to clarify PBI's in a way that will enable good planning, not to brute-force a standard that may or may not be applicable.

Artificial restriction

A "user story" is actually not something created by the Product Owner, but real needs of real people. The reason for "user story" vs. "requirement" is this: We want to move away from prescriptive, inefficient solution proposals created by people with limited understanding of existing capabilities and constraints. Storytelling enables teams to move towards an open solution space, from which technically excellent developers can pick the optimal approach to meet the real user need.

Wrong focus

"User stories only" can result in valuable work being omitted or delayed because no "user" can be found, or simply: Because nobody has an idea how to rephrase the need into something that matters to users. Teams should not exclusively focus on users, but also on creating a sustainable, valuable product. Instead of looking for ways to shoehorn a description for needed change into an unsuitable format, teams should learn to communicate technical activities so that all parties understand why they need to be prioritized.

No discussion

The worst part about "User Storys in the Backlog" is a kind of not-my-job thinking. The Product Owner has to turn requests into workable "user stories" before the team will work on them. The core idea behind a "user story" is a discussion happening between those who have a need (user) and those who can help (the team).
The intention is dialog, the backlog item should merely be a reminder of a discussion that either has happened or still has to happen.


By moving a backlog to a "User Story Backlog", we induce waste and create a wrong mindset. Once the wrong mindset is established, we've managed to simply re-label traditional Requirement Engineering, devoiding agility of it's core benefits.

Remedies

Team members need to understand that the format of backlog items is actually irrelevant as long as they have a clear understanding what is needed why.

The Product Owner needs to understand that "user stories" are good where they help, and useless otherwise. The PO's job is not to make sure everything is written as a user story, but to ensure that the most valuable things are done first.

When talking about User Stories, the Scrum Master needs to emphasize that the point of stories is dialog, not form.

Educate everyone that it's completely acceptable to use whatever kind of label and form for backlog items that are helpful to understanding.

Resist the urge to re-label "feature requests" or "requirements", simply accept that you get these things. Examine why you work with these things rather than with real people having real needs.

Move the developers away from being request executors towards becoming innovators, then the form will become irrelevant.