The Story Behind User Stories
Starting off my new role as a Business Analyst, I have had a week-long refresher course on the ‘right’ way to write User Stories.
‘Right’ in quotes, because there really is no right or wrong way to write a User Story. All you have are a set of guidelines and common practices, all of which are only tried and true methods as experienced by your peers.
A User Story is somewhat of an enigma. Primarily, it is meant to be a way to communicate requirements to developers so that they know what to build.
However, at the same time, User Stories must also express to the business why this feature is being built and what business value it promises to deliver.
The fact that a User Story has two sets of very different audiences, one technical and the other (most probably) profit/business oriented is what adds to the complexity. It’s like trying to write a novel for both sci-fi geeks and C-suite executives.
What I was reminded of this week was that a User Story must tell the narrative about a particular user behaviour with the product. It is a story in three parts:
- Who the user is
- What they’re doing
- Why they’re doing it
I like that we conceptualize these artifacts as ‘stories’ since stories are usually associated with the ‘why’ behind human behaviour. Journalists seek out motivations behind the humans in their news items in order to make their story richer and more compelling.
That third part, the ‘why’, is important not only because it is the red string that allows both the tech-savvy developer and the business-minded executive to agree on a universal goal that the User Story is trying to achieve, but it also provides the reasoning as to why the user will behave in that particular way.
The ‘why’ is always written from the point of view of the user. The ‘why’ is never “to increase profits by 20% in the next quarter” or “to save on annual storage costs”.
The ‘why’ always focuses on serving the user.
The ‘why’ can also influence design decisions. Does this User Story have the purpose of entertaining a user or is it intended to make their life more convenient? This may be the difference between creating a simple button or having a dancing hippo pop up on your screen.
When we are in the early stages of building a product, we are focused on all the things that a user will be able to do with it. We go wild with our imaginations and that’s perfectly OK.
But with every user behaviour, we need to ask ‘why’. Why would the user want to do that? How does that behaviour impact their lives? How will this feature serve the user?
Once we start asking ‘why’, then we’ll create products with more impact. Because then, behind each user action lies a great story.