“A user story is a promise for a conversation”
Attributed to Alistair Cockburn
Great product teams understand and solve complex problems in innovative ways. They approach problems with an attitude of discovery and learning, trying to formulate and validate product experiences to provide value and impact for users and businesses.
Building the right solutions to complex problems can be overwhelming due to the sheer size of effort, domain complexities and the coordination of many moving parts. Much goes into crafting amazing product experiences and this is where user stories can really help product managers.
When I started my career in the late 2000s, it was common for projects to create large amounts of documentation about what their teams were to build. These documents were written and handed over to delivery teams to build, test and deploy in a timely fashion. The result was long delivery times, and even though the product ended up in the user’s hands, it didn’t quite solve the problem we were trying to fix. Between writing the document and having the product release, things changed and we missed the opportunity to learn and adapt.
User stories are the opposite of long, written documents – they’re an informal description of product capabilities from the perspective of an end user. They articulate how a feature would behave and the outcome provided to a user, representing the leanest slice of work that delivers value.
Introduced by Kent Beck in the late 90s, user stories have become a means of forming a shared understanding of what to build and who to build it for, identifying the most economical ways of delivering value, and avoiding large quantities of documentation.
If you’re after more on this, I strongly recommend having a read of Jeff Patton’s User Story Mapping. It’s a great technique, and one I’ve adopted many times to help teams map and visualise all the moving parts, especially if your team isn’t sure where to start.
Product managers and user stories
Creating user stories is a core feature of agile delivery. Product teams utilise user stories to tackle big problems by breaking them down into smaller, deliverable chunks of work that provide value and align to the bigger picture. They help us remember the people we’re building for – the consumers of our product experience.
The way product managers utilise user stories vary – sometimes product managers trust their teams to manage this process and don’t write any stories themselves, and other times product managers are embedded in the flow of writing cards and feeding the backlog beast. There are pros and cons to each style.
Another way to look at this is to appreciate that each team and organisation exist in their own realm, and are working to the best of their efforts to succeed. Their ways of working are unique, and it is the collective team that decides which roles and responsibilities best suit their ecosystem. Although product managers should always be curious, strategic, outcome-focused and insights-driven, they should also be adaptive to the team’s best ways of working.
User stories can help product managers to convey the purpose, impact and value teams are creating for users. User stories and story mapping can help product managers paint the overarching vision by connecting product vision and project purpose with the goals and outcomes of each feature the team builds.
Working with user stories
Creating user stories does not necessarily involve writing hundreds of cards that end up in a backlog for prioritisation, or needing to write the perfect specification across your cards. It’s about sharing stories with the wider team to help build shared understanding and bring focus to a common problem, and from there, deciding on your direction as a team.
User stories are like pieces to a massive puzzle – they help product managers collaborate with engineering and design folk to break down complex problems and look at the bigger picture from different angles. By doing so we’re able to spot potential complexities and opportunities, helping teams coordinate, plan and build the right solution.
In particular, product managers can facilitate user story slicing to help product teams understand that not everything needs to be built at once. Through iterative development, we can slice up a big problem into smaller components and help prioritise which aspects must be built first and which should, or could, be built later. This gives product teams the flexibility to learn fast and deal with uncertainty by building early and releasing often!
Product managers can utilise user stories as a way to help highlight the purpose and outcome of what a team is building and to empower them to always ask questions. Stories harness collaboration and shared understanding, allowing teams to question how they can best provide value to the end user.
From a stakeholder and partnership point of view, product managers can apply the same user stories to design product roadmaps and run showcases that articulate how we navigate uncertainty by building to learn. Describing user story outcomes helps show stakeholders what a team is building, aligning everyone, from various delivery and support teams to business sponsors to the product experience we’re crafting.
Of course, user stories can be overused and stories can be written for the sake of capturing requirements, writing lots of detail and filing them away into an ever-growing backlog of work. When this happens, each iteration turns into a tiresome battle of card trading, deciding which stories to play or not. Whether scrum, kanban or something in-between, the intent of user stories are long forgotten due to agile rituals, estimation and release pipelines.
This is when it’s important to reflect and go back to basics – to remember the purpose of user stories and their ability to provide value. As product managers, we’re ideally placed to guide teams to question the purpose and desired outcomes of a user story, not necessarily by writing it all down and estimating the effort, but by providing the medium to discuss and evolve.
As teams work with user stories, they continue to build and learn, and it’s the conversations around a story’s intent that helps guide them through decision making. Keeping documentation light and using visuals and sketches can help teams to develop a shared understanding of what they’re building.
Stories are conversations
As Alistair Cockburn coined “A user story is a promise for a conversation”. This was my introduction to crafting user stories and has continued to be a humble principle in how I combine product management and stories to engage, collaborate and empower teams to solve big problems.
User stories are a great storytelling mechanism to connect the many aspects of a project, from goals, hypotheses and experimentation through to the individual capabilities that teams build. User stories facilitate conversations to form a shared understanding about what we build and how they provide value to an end user within a product experience.
Need help breaking complex problems into smaller delivery chunks with an inspired team? Come talk to us, we’d love to help.
If you’re keen to explore more about user stories, here are a few interesting links:
- Agile story essentials (Jeff Patton)
- Story map concepts (Jeff Patton)
