User stories are a powerful technique to capture the product functionality from the perspective of a user or customer. But how do we discover the right stories? When should they be written and how detailed should they be? Read this post to find out my answers to these questions.
1 Create Personas
The first step towards writing the right user stories is to understand your target users and customers. After all, user stories want to tell a story about the users using the product. If you don’t know who the users are and what problem we want to solve then it’s impossible to write the right stories and you end up with a long wish list rather than a description of the relevant product functionality.
Personas offer a great way to capture the users and the customers with their needs. They are fictional characters that have a name and picture; relevant characteristics such as a role, activities, behaviours, and attitudes; and a goal, which is the problem that has to be addressed or the benefit that should be provided.
Let’s look at an example. Say we want to create a game for children, which is fun to play and which educates the kids about music and dancing. We could then create at two personas, one to represent the children, and one for the parents, as shown below.
The two sample personas above use my simple yet effective persona template. It encourages you to keep your personas concise, to focus on what really matters and to leave out the rest. You can download the template from romanpichler.com/tools/persona-template where more information on writing personas and using the template is available.
Once you have created a cast of characters, select a primary persona, the persona you are mainly designing and building the product for. This helps you make the right product decision and get the user experience (UX) right. In the example above, I have chosen Yasmin as the primary persona.
2 Derive Epics from the Persona Goals
Once you have created your personas, use their goals personas to identify the product functionality. Ask yourself what the product should do to address the personas’ problems or to create the desired benefits for them, as the following picture shows.
Start with your primary persona and capture the functionality as epics, as coarse-grained, high-level stories. Write all the epics necessary to meet the persona goals but keep them rough and sketchy at this stage.
For the dance game, we could write the epics to allow the players to select different characters, to make them dance, to choose different dance floors and music tracks, to play the game with their friends, and to post a snapshot of their game on social media.
While epics are great to sketch the product’s functionality, there is more to your product than epics and stories: You should also capture the user interaction and the sequences in which the epics are used, the visual design of your product, and the important nonfunctional qualities such as interoperability and performance. Use, for instance, workflow diagrams, story maps, storyboards, sketches, and constraint cards to describe them. You can find out more about describing the different product aspects in my post “User Stories are Not Enough to Create a Great User Experience”.
3 Progressively Refine the Epics into User Stories
With a holistic but coarse-grained description of your product in place start progressively breaking your epics into smaller stories. Rather than detailing all epics and writing all user stories upfront, you derive your stories step by step as the following picture shows.
As long as there are some significant risks present and you are figuring out what the product should look like and do, it’s best to derive just enough user stories just in time for the next sprint. Use your sprint goal to determine which epics to decompose and which stories to write as the following diagram illustrates. This approach depicted above minimises the amount of detailed items in your product backlog. This makes it easier to integrate new insights derived from exposing product increments to users and customers.
Once you have addressed the key risks, you can start pre-writing user stories and have a larger inventory of detailed items on your product backlog, as your backlog is unlikely to change significantly.
4 Get the Stories Ready
Before the development team starts working on the stories, check that each user story is ready: clear, feasible, and testable.
A story is clear if there is a shared understanding between the product owner and the team about its meaning. It is feasible if it can be delivered in the next sprint according to the Definition of Done. This implies that the story is small enough to fit into the sprint but also that the necessary user interface design, test, and documentation work can be carried out.
With ready user stories in place the development team is in a good position to progress your product in an effective manner. For more details on getting user stories ready please take a look at my post “The Definition of Ready in Scrum”.
As far as I know, Mike Cohn was the first person to suggest deriving user stories from personas. Mike writes on p. 31 in his book User Stories Applied: “The disciplines of user-centred design (…) and interaction design (…) teach us the benefits of identifying user roles and personas prior to writing stories.”
The persona pictures were created by Ole Størksen.
Post a Comment or Ask a Question
Can you share some examples on how to write epic ?
Hi Ashish, Thanks for sharing your question. You can find a sample epic in the article “Epics and User Stories”. Hope this helps!
Roman, have you ever established governance around defined personas?
Nope, sorry. Why would this be useful please?
It seems to me that the first persona to develop would be the project sponsor. This is the person who has made the difficult decision to spend hundreds of thousands of dollars to solve a business problem. If you don’t capture that decision process and motivation you may miss the mark entirely. It must define a theme for the whole project. This is also the stakeholder who will be least available for input. Generally we see highly developed personas for end users, and while their interaction with the system is important, their understanding of the high-level problem to be solved is often limited.
Hi John, Thanks for your comment. I understand where you are coming from but I don’t agree. While the sponsor is an important stakeholder, personas are user models and should capture the people who will use and buy the product. A product’s success ultimately depends on how well it meets the needs (or goals) of the users and customers. If people don’t find it beneficial then the product is unlikely to achieve its business goals, such as meeting a revenue or profitability target, selling another product or service, saving cost, or enhancing the brand equity.
I totally agree. Personas are about user models. The project sponsor is your major stakeholder and an analysis of them would have been captured in your stakeholder analysis.
^ This ^
Please what modelling language can be used to describe a persona? or the requirements of a persona including the picture.
if not, what do you think the solution can be?
Hi Viva, You may want to try my persona template to describe your personas:
Hope this helps.
Should a UX Designer essentially be the Product Owner of the Scrum Team?
Great question. You can find my answer in the following post:
Hope this helps!
Sehr netter Artikel zum Thema wie komme ich von Personas zu Stories. Das kommt leider in den meisten Projekten etwas zu kurz.
I should point out that, in your example, all of the decomposition takes place along functional lines. I recommend decomposing epics and user stories along nonfunctional lines in some cases.
Thanks for your feedback Roger and for sharing your alternative to functional story decomposition!