We must stop writing ‘user’ stories and start writing human stories.
User stories — are out of date. Suppose you’ve worked in any facet of product delivery over the last 20 years. I’d wager you’d have used a construct of trying to describe what a ‘user’ wants and spent much time doing it.
Why do teams do this? There are many reasons, I think, and good ones, too; it’s served a purpose.
How did this all come about?
User stories we use today in modern-day technology practice are a construct that first emerged in the late 1990s. Programmers and technologists started to describe technical specifications with users in mind so that engineers alike would better empathise with who and what they were building.
Agile was and is the methodology that has risen to be industry-leading. It promotes iterative and incremental development, emphasising flexibility and collaboration.
XP (Extreme Programming) Practices: XP, introduced by Kent Beck in the late 1990s, was one of the first to discuss and raise Agile methodologies. The concept of user stories was further popularised by Ron Jeffries, one of the original authors of the Agile Manifesto. (Ron now also claims developers should abandon Agile — I’ll let you read those thoughts here).
Mike Cohn, another prominent figure in Agile and Scrum, introduced the “As a, I need, So that” format for writing user stories. This is the most typical and standardised format you’re used to seeing today.
Let’s look at the description Mike gives us on his website.
User stories are part of an agile approach that helps shift the focus from writing about requirements to discussing them. Every agile user story includes a written sentence or two and, more importantly, sparks a series of conversations about the features and functionality the user story represents.
Let’s break this down: As a user — I want something so that I can benefit from it. It is probably the worst story you could ever tell about a real human being. Let’s be honest: if our children’s books were written like that, you wouldn’t be captivating and nurturing the minds of our future.
I love engineers. Let me state that openly and clearly. Designers and Developers would all do well to live in harmony and peace. However, we now use ‘user stories’ to describe real human needs and wants. Some very clever engineers wrote them.
Three decades ago. It’s time for a change.
Artificial intelligence is changing the game.
No shit Sherlock. The problem we as a community now face — and yes, the clickbait attention-grabbing point we all feel we need to embrace and make now — is the ever-looming rise of ‘Skynet’ and A.I.
I would argue that ‘As a user’ could be non-human. We could, in theory, soon be designing systems for robots and machines to use.
As designers, developers, and product thinkers, we must start to separate this concern — right now. Humans should come first in the race; it’s what we’ve done throughout history, and ultimately, our existence depends on that.
What makes a good story?
All good books, stories, fiction and non-fiction have a main character. They are often faced with a problem or adversity.
They have needs, wants and goals. Sometimes, they may not be apparent in any of those things.
Human stories usually have details about their personality (persona).
The great news is that the stories you must write can be unfinished. As a team, you get to decide through hypotheses and learn the best solution for your human tale. These are short stories that you get to try and measure the effectiveness of their being with the main character.
As a customer who struggles with technology and reading smaller screens, I often won’t use something if the text is too small or the screen is dimly lit. I sometimes need to get others to help me use devices. I have a problem knowing my store card information and how many loyalty points I have. I like talking to and interacting with staff; I want to be shown how to do things. I want to spend my earned points and know about offers I’m entitled to.
Off the back of that story, as a designer, I could take it and look at existing user journeys and conceptualise. As a developer, I could spike an investigation into how to store card data and how technologies currently work. As a product manager, I could think about other teams and stakeholders to enlist for information and build an objective around customer retention, looking to build on the results of those customers spending more money.
Ultimately, the outcome for the team will be to spend less time writing user stories, understanding their humans and getting stuff into production faster. Get your ideas and solutions back to the actual humans who you think need your solution. Give yourself more chances to fail and do better.
How do we incorporate this into our current ways of working?
For me, in agile delivery, there’s an opportunity to define the human stories higher up the chain. Epics are an excellent opportunity to set out these stories and link them to research, problem statements, and other artefacts relating them directly to humans using your products. Underneath that, you can have development tasks, spikes, or whatever you need to link to the human story you are trying to unlock.
Resources: