# The illusion of lean: User stories vs User problems

- Link: https://www.solmesz.com/articles-en/illusion-lean-user-stories-vs-user-problems
- Published: 2019-01-29T12:54:06-03:00
- Author: Sol Mesz

[(Leer en español)](https://www.solmesz.com/es/blog-es/illusion-agilidad-historias-de-usuario-vs-problemas-de-usuario)

If you look for the definition of “user stories” on the Internet you’ll find a lot
of different answers, perspectives and methodologies to create them. As usual, [Wikipedia sums up pretty well all of the information that’s out there](https://en.wikipedia.org/wiki/User_story):

 * They are used in software development
 * They are used to describe features but written from the perspective of the end
   user
 * They help teams understand the context of the functionality
 * They are validated (if anything) with internal clients (stakeholders)

There are two common threads here: one is that user stories are an IT instrument.
The other is that _no one mentions that they should come from actual user observations_.

**And that is the big problem with user stories**: they are features disguised as
user needs that, more often than not, are not validated with actual users. They 
are merely hypothesis.

Typically, user stories are written by development teams as a group activity or 
in the context of a workshop. When teams say that they got the needs from “the users”,
they usually mean stakeholders, end users.

The few times where actual end users take part in the process, more often than not
these stories come from a process of [requirements gathering rather than an assessment of needs.](https://www.solmesz.com/blog-en/gather-requirements-assess-needs)

## **The illusion of lean**

**The fact that no actual user is involved in the process of writing user stories
may feel very agile and lean. But the reality is that it is the complete opposite**:
building features without actual user research saves time, but it is costly and 
creates a lot of waste.

Here’s an example. We were once working on a B2B platform where users logged in 
to download information that they used to make reports.

Before we had even started the project, the Development team had written a few user
stories and even developed a few screens based on them. One of those screens involved
the login process.

Their user story for the login read something like “_users want to use Gmail or 
LinkedIn as an easy way to login_”. However, that was just a hypothesis, since they
didn’t run any user interviews.

They had just looked at various sites (likely B2C ones) that used this type of login
as a way to simplify and speed the login and thought “_that would be a good idea
for the system we’re building_”. So the login screen had 3 options: login with Gmail,
LinkedIn or an email of your choice.

When we run usability tests on the login flow we discovered that users did not want
to use personal accounts or social networks to log in to a system that they used
for work: _“I’m not going to use my Gmail/LinkedIn account for this. This is a work
system. I don’t want them to see my personal information”_ most of the said.

Fortunately, we were testing prototypes and nothing had been built yet. If we hadn’t“
wasted” time (and therefore agility) validating with users, the Development team
would have built a functionality that no one would use merely based on an assumption
that looked like a good idea and that made sense because other sites used it.

So all this time that was supposedly saved by not talking to users would have ended
in a big waste of time, resources and, most importantly, time to market.

> **And that is the illusion of lean**: thinking that we save time by not talking
> to users when most of that time ends up being used anyway in the form of refactoring
> or, even worse, wasted altogether by building something nobody uses.

## **User problems vs user stories**

So making a distinction between actual user problems and user stories is key if 
you really want to be agile and lean.

### **User problems**

 * They express an actual problem or need a user encountered while using the system
 * They are validated observations that come from user research
 * They are part of a flow or task the user is trying to accomplish and not isolated
   observations
 * Bring and outside-in perspective

### **User stories**

 * Tend to be requirements disguised as user needs
 * They don’t typically come from user research but are assumptions made by IT teams
 * They are usually disconnected statements
 * Represent an inside-out perspective

## Being lean: “saving time” by talking to users

In other words, user stories should describe an actual user need or a behavior as
observed during user research. Then, and only then, these problems will be translated
into user stories in order to define a feature. **This is the only way in which 
development teams can be truly agile and lean.**