From Personas to User Stories

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

---

Notes

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.