Mastering User Stories – Part 1 | User Stories Unpacked: The Power of Conversations
A guide for Product People to discover why user stories are about conversations, not documentation, and how to foster true shared understanding in your team
Welcome to the first instalment of the “Mastering User Stories” series! Over this four-part journey, we’ll dive deep into transforming your user stories from mere documentation into powerful tools for building better products and fostering shared understanding within your team. Before we dive into the “how-to” of writing and sharing, it’s essential to grasp the fundamental purpose of user stories, as this understanding underpins all effective product development. In this article, you’ll discover where user stories come from and practical ways to achieve shared understanding.
When I started out in product management, I was so focused on finding the right structure of writing a user story. I used to think that if I wrote the “perfect” story and my developers immediately understood what to implement, then I was doing a good job. Over the years, I realised that having a succinct, clear user story is only a small part of the process.
Of course, there is a widely used template that most people working in software development use:
Title
As [a user persona],
I want [to perform this action]
so that [I can reach this outcome].
Acceptance criteria
But the purpose of a user story is far from being just a written document. And to discover why, we have to go back to the origins of user stories.
Where do user stories come from?
, one of the founding fathers of Agile, the creator of Extreme Programming, and the one who popularised test-driven development, also came up with the concept of user stories. He initially called them “stories”, because they are intended to spark conversations, and to move away from rigid document-heavy requirements gathering. The goal of user stories is to foster a shared understanding within the product team – developers, designers, product managers, and potentially other roles – regarding the outcome our user aims to achieve.Shared understanding happens when we all understand what the other person is imagining and why. To achieve this, it’s extremely useful to externalise our thinking. Often, we believe we understand the same thing, but the moment we start drawing, asking questions of each other, and visualising our ideas, we realise we weren’t on the same page at all.
Once we reached shared understanding, we should document what we agreed on. The most important part, though, isn’t what’s written down, but what we remember when we read it.
How to achieve shared understanding
Over the years, I saw many people struggle with employing user stories effectively, leading to frustrated teams and faulty products. Often, the problem wasn’t what was written down, but what wasn’t discussed.
Software development thrives on complex communication, but this complexity often creates fertile ground for misunderstandings. From brainstorming endless possibilities to nailing very precise details, product teams constantly navigate a vast communication spectrum. In this process, misunderstandings can frequently occur, causing misalignment within our team. Fortunately, by employing the practical techniques we'll explore below, you can significantly minimise these communication breakdowns and foster genuine shared understanding.
When used well, user stories can really spark critical thinking among our product team, fostering collaboration and leading to better products.
❌ Don’t do this
Shared documents don’t imply shared understanding. Don’t just pass on the user stories to the developers, hoping that everything is clear, as it won’t create shared understanding. If you try to save time on discussing what your users want to achieve and why with the developers and designers in your team, then you risk ending up like the creators of this cake below.
Don’t believe you need the have all the answers yourself. In my first product owner role, I didn’t initiate many conversations within my team about the overarching vision of what we were building, the reasons behind it, and the most efficient ways to achieve our goals. I even thought I had to have a clear plan of how to implement each user story, otherwise I would be seen as a fraud. Well, obviously, that wasn’t what made my stories work. Your cross-functional team is there, so collaborate with them.
✅ Do this
The goal is creating value, not shipping features. The underlying thinking is that we don’t just want to ship a feature, we want to create value for our users and our business. To do this, we need to approach everything we build by asking those key questions to make sure we’re tackling the most important user problem and developing the right solution:
“Who is our target user?”,
“What problem are we solving for them?”,
“What is the solution we are proposing to solve that problem, and why?”
So, discuss these details with your team, instead of presenting them requirements.
Show the whole user flow. Before I show a user story to my team, first I like to guide them through the whole user flow – ideally through a clickable prototype. It can happen in collaboration with the designer who created the prototype. This way everyone sees the big picture and understand how the process will work from the user’s perspective.
Read the story out loud. Don’t just rely on your team to read the story, but share your screen – if you’re in an online or in-person meeting – and read the story out loud. So, they both see and hear it.
Ask for questions and look for confusion. One underrated step of any meeting is checking if participants have any questions or comments. If you see one of your team members looking confused, ask them, “Luis, you look a bit sceptical. What are your thoughts?” This will help also your introverted team mates to express their opinion.
Use complexity scoring to verify shared understanding. In my opinion, one of the main objectives of giving a complexity score to a story is to check whether the developers agree on the scope of the story. You can use fibonacci numbers (0, 1, 2, 3, 5, 8, 13) or T-shirt sizing (S, M, L), it doesn’t matter. The discussion is the important part that is triggered by these scores. You might have to prompt this discussion to happen by asking, “Annie, why did you score it 3?”
Putting it into practice
Ultimately, building shared understanding comes down to transparent discussions and visualising ideas as a team. As Kent Beck wisely put it, “Stories are really placeholders for conversations”. Don’t just take my word for it. Try applying one of these conversational techniques, like talking through the problem you’re solving or using complexity scoring to spark discussion, in your very next refinement session.
In Part 2 of this series, we’ll move from understanding to action, delving into practical ways to slice your stories, give them succinct titles, and ensure they truly represent an end-to-end user outcome.