How to write a great User Story for product planning and development
‘How do I write a great User Story?’ has to be one of the most common questions and requests I’ve heard over the last 10 years.
The second part of this question normally comes from someone senior who wants to get a ‘standard user story template’ that can be used to drive consistency and standardization for requirements in an Enterprise. The problem with the question is that it doesn’t really focus on the right outcome and assumes user stories are just a new form for capturing and disseminating requirements. So, what should the right focus be?
Delighting the user
User Stories have always been a promise for a conversation – as Ron Jefferies used to say: card, conversation and confirmation. Not a detailed specification that replaces the need for makers (developers, engineers, analysts, designers, etc.) to talk to users and product owners.
The true outcome of the process of discovering what users need, understanding those things and designing something that really helps is a working product or service that knocks the users socks off. If you manage to write beautiful stories with amazing acceptance criteria yet fail to build a great product that completely satisfies the user then the focus was probably wrong. The focus should be on building a solid, shared understanding of a user within the development team. Anything other than that is waste.
Format doesn’t matter
Over the same decade of hearing the how do I question I’ve been involved in many debates about user story formats. Some people prefer a simple card with a title that reminds them about the topic. Others prefer to use the classic canonical form. Some prefer to flip the canonical form to focus on the goal first. Whatever your preference on format, it’s worth examining the canonical form to give us a clue as to what to focus on:
As a <User Persona>
I want to <Action>
So that (I can achieve) <Desired Outcome>
The name User Story and the first line of the model gives us a clue where time and energy should be spent – on the User. In most conversations about User Stories someone will mention that a great story will adhere to the acronym INVEST – it should be Independent, Negotiable, Valuable, Estimatable, Small (enough to fit in your timebox) and Testable. This is all good advice and worth following, but the problem is much of the time the really hard thing is breaking down work into something that is truly valuable, independent and small enough. The User (hopefully your Customer) is the person who you really need to satisfy and it’s in understanding them that help can be found. The bottom line is whether you’ve created something that does solve their problem in a way that delights them. So, to write a great user story you must spend time creating a clear picture of a customer and ensure that you and your development teams share and understand that picture well enough to craft working solutions that solve their problems.
Understanding your customer
There are many tools and techniques you can use to understand customers. You might choose to observe them going about their day to gain knowledge. You might explore a complete design thinking process to identify a number of key insights. You might use ‘jobs-to-be-done’ to figure out what they really need. Whichever method you choose to analyze a user, consider creating a Persona to capture your thoughts and to communicate your insights to the wider team.
BUILDING PERSONAS
- Conduct customer research and gather all available insights to understand the target customers’ mindset, motivations and behaviors.
- Identify behavioral variables, which are aspects of behavior and attitude that could differ between customers. Ease of use, price sensitivity and quality expectations are all common types of variables.
- Once you have identified a list of variables, use these as a basis for comparison. They can be laid out on a set of sliders with opposing behaviours placed on either end. Mark out where each participant would sit on each slider based on what you know about them.
- Analyze the grouping of the behaviors across the sliders, identifying trends where the same participants are grouped together across multiple variables. These grouping trends across all the sliders will then form the basis of your different personas.
- Design a template and draw up your persona groups.>
- Refine these personas and make them realistic using names, photographs, quotes, etc.
- Display your personas – online, on the wall, etc.
Things you might want to capture in your personas:
- Persona group (i.e. Web Manager)
- Fictional name
- Job title and major responsibilities
- Demographics such as age, gender, education, ethnicity, and family status
- Background and experience
- Goals or the jobs-to-be-done
- Motivations and pain points that drive their ideas and behavior
- A quote that sums up what matters most to the persona as it relates to your product
- A photograph that represents that persona
The best starting point for a great user story
The best stories have the strongest and most identifiable characters – people you can connect with. Creating knowledge about real users is essential. After that you can tackle the tough problem of breaking features down into something that could be incrementally delivered or something small enough to get feedback to know you’re going in the right direction. With a clear picture and real insight into real users you can do that. Start here. It’s your best bet for crafting a solution that really works and amazes your user.
Additional Insights
The art of feedback
Process mining for customer journey mapping
The importance of owning your transformation
