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:
- 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.
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.
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:
- 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.
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.
