As a Business Analyst, user stories a big part of my day to day job. They set the baseline for the whole software delivery lifecyle. If the user stories are wrong, the software that gets delivered will be wrong. That’s a fact.
Even though user stories are fundamentally the same thing as traditional requirements, they differ in many ways, most notably the format. They introduce the concept of a “user”. But we don’t always give the user the attention they deserve.
Not only may we take for granted who the user is in many of our stories, but we can also take for granted what they want too. But… are we always right?
Let’s take an extremely simple user story as an example, one that has probably existed in the backlog of many an agile team:
As a customer,
I want to register as a user,
So that I can login and use the system
But if we take a step back, maybe jump into the customers boots, is our want really to register for the system? I’m not sure about you, but when I open up (let’s say the Spotify web app), my first thought isn’t…
“you know what? I really want to give Spotify all my personal details”
It’s more along the line of…
“I want to listen to some awesome music”
So, what is the want of the customer? Maybe we should write the story this way instead?
As a new Spotify user,
I want to access the Spotify Web app,
So that I can listen to some music
So is there a need to register? Probably yes. But does anyone really want to register, or log in?? Or is registering for an account and logging into that account just a means to an end, a method of providing some functionality that a user will find valuable?
How about the following user story?
As a Spotify Premium Member,
I want to keep a set of personal playlists,
So that I can listen to my favourite songs over and over (and over)
The detail, or functional specification, could then describe how the users are required to log into their own account in order to meet such a story. The act of logging in itself isn’t really something the user “wants”.
The logging in function could also be desired by other user stories, from entirely different types of user too:
As a Spotify Marketing Manager,
I want to be able to identify what songs specific users listen to,
So that I can make lots of money by spamming them with artist related adverts
In order to do so, you’d need to be able to identify and track individual users, making them create accounts is one method of doing so.
The stories we tend to write can easily be misleading, and can lead us down a false path. For example if we used the first user story, we may have spent a lot of time on the user registration feature, because we wrongly thought the user really wanted this feature. They didn’t, what they really wanted was to start listening to music. We know this because we scrapped the first story, and the second story allowed us to understand the real want.
As such, maybe we spent less time on the user registration feature, maybe we even made it as simple as possible to register so the user has less blockage in the way of reaching their want, to listen to some music.
And maybe… just maybe… we ended up with a happy user at the end of it.