From Personas to User Stories

By Roman Pichler, 13th August 2014
Photo by David Cohen, courtesy of Unsplash

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 Start with 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 would then create at least two personas, one to represent the children, and one for the parents, as the following picture illustrates.


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 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 below assuming that the game will be initially launched as an iPad app:


As the epics above show, the game should 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 Facebook.

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, mock-ups, 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 or hypothesis to determine which epics to decompose and which stories to write as the following diagram illustrates.


The 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 or minimum viable products (MVPs) to users and customers.

Say that we want to address the risk of creating the wrong game characters by developing an executable prototype that allows us to run a usability test with selected children. We could then write the following user stories:


The stories above are derived from the epics “Choose character” and “Play with character”. The resulting prototype only partially implements the two epics – just to the extent of being able to test if the characters resonate with the users.

Once you understand better how to meet the customer and user needs, you can start pre-writing user stories and have a larger inventory of detailed items on your product backlog as you are unlikely to experience bigger changes to your epics and your overall backlog.

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.

In the case of the sample stories above, we would have to add acceptance criteria, ensure that the stories are small enough to fit into the next sprint, and consider creating some very rough design sketches to indicate what the characters look like. For instance, to get the story “Yas chooses the little girl” ready, we could create the following rough sketch:


The sketch above complement the user story and allows the team to implement the entire story including the visual design in the next sprint.

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”.

Article Name
From Personas to User Stories
Find out how to discover the right epics and user stories from personas and how to progressively refine them.
Pichler Consulting Limited

Learn More

You can learn more about writing the right epics and user stories with the following:

The persona pictures and the Manga girl sketch were created by Ole Størksen. Thanks Ole!


RSS Feed

Tags related to this post:

12 comments on “From Personas to User Stories

  1. John Durgin

    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.

    • Roman Pichler

      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.

  2. Viva

    Hi Roman
    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?

  3. Michael

    Should a UX Designer essentially be the Product Owner of the Scrum Team?

  4. Allen

    Sehr netter Artikel zum Thema wie komme ich von Personas zu Stories. Das kommt leider in den meisten Projekten etwas zu kurz.

  5. Roger L. Cauvin

    Roman, excellent procedure for driving the user stories for a product. I like the way you laid out the epics in terms of user goals, the decomposition, and the reminder to capture nonfunctional requirements as well.

    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.

    • Roman Pichler

      Thanks for your feedback Roger and for sharing your alternative to functional story decomposition!

Leave a Reply

Your email address will not be published. Required fields are marked *