Bruno Peeters Technical Blog

Agile encourages building software with the end user in mind. It will then help to have a clear and common understanding of this end user within the team. Therefore you can use a so-called persona. Personas represent fictitious people, based on the teams knowledge of the end user. Within this persona you will together write all the details that are of interesting when defining the user stories within your project.

The use of personas

It can be quite convenient to skip the work for really getting to know your end user. We all might think we all know the ins- and outs of our customer. But is this really so? By going to the process of defining personas, you are enforced with your team to think about all the details of the end user. Discussions will start, that will bring up new insights to the table. You will together see what the end user’s real problem is and which solutions will fit best, which will help during story mapping.

It will also help new team members to be introduced within the project. By explaining the personas, the vision of the project becomes much sooner clear to these new members.

Personas will help when defining new user stories, especially when thinking of alternate scenario’s. The persona will live in the heads of the team members, making it easier to put themselves into the shoes of this end user.

Getting started

You can start to define a persona for each of your end users, but typically one kind of user will have multiple personas, just like not all readers of a certain book will wear the same clothes and watch the same television series. So it can help to define a couple of personas for just one kind of end user.

Start with your team to investigate the end users of your system. What kind of personalities do you see? Which commonalities do they have? What is the average age of the users? What kind of issues do they face?

Defining your personas

Start with a name that is easy to remember to the whole team. Then come up with an age and where the persona lives. This will give your persona it’s initial characteristics.

From there on you will define the (job) title of your persona, which defines the relationship that he or she uses when using your software. If software is used as a teenager who is gaming, the title can be for example wannabe world champion gamer.

What will the persona be in real life? This gives him or her more personality. The gamer in our example can be a student. Being a student can give away that our end user doesn’t have that much money, which can influence the number of features we can provide for free to such a user. What other details of your end user can be important for the persona? Write them down.

To have a general visual lay-out or include the same kind of data over all your personas, you might want to think of defining a template. This template will also help you speeding up defining the personas, since you will now already have a couple of directions where you could think of when defining the persona.

Also make sure you draw a picture of your persona, giving it some visual appearance. Maybe you can find a stock image or you even might find out one of your team members is a great visual artist drawing people.

Redefining

All doesn’t have to be written into stone. The team can add details later on during the project, when you find out new things about your persona. Also it can be the fact the team isn’t yet sure about some elements of the persona. Write your questions also down, it can be become clear when moving on during the journey of your persona. The persona can be redefined during the development cycle, being true to agile.

An example

The following example shows a persona for a game connect 4.

We provided some general details of our persona in the beginning. It shows his age and where he lives, that makes it easier to identify with him.

In the next section we went deeper into the details of our persona: what he likes and doesn’t like. This will help us when making decisions when defining our user stories.

The last section shows the goals; what is very important for our persona. This will be most of the times the goals that needs to be statisfied within our product.

Sharing

Now the personas are defined, it is important that they will be easily accessible and visible by all team members. Put them besides the sprint backlog or close by your backlog. This will keep the whole team aligned, and makes it easier to discuss new user stories or explain and discuss stories.

Occasions where personas have less value

There are scenario’s where a persona has less value. For example when we want to build a product that serves a small set of users. Or a product that doesn’t have any end users. Think for example a internal library.