This is about the use of personas, primarily in the agile development realm.

What value, if any, do personas give during implementation?
On agile modeling, the discussion about personas remains in the context of requirements investigation.
On wikipedia, the benefits are described to "assist with brainstorming, use case specification, and features definition."

I'm familiar with personas in use while writing user stories such as the following:

As Willow, I want ordering a combo meal to give me the option to select alternate sides.
As Xander, I want the default side to be selected when I order a combo meal.

In these examples, Willow is the nutrition-conscientious user of meal-ordering software and Xander is the hungry, impatient user that thinks "fast food should be fast."

When coming up with these requirements, it may have been helpful to have the personas in mind. I imagine a possible discussion:

Person 1: Willow needs to have more options than fries for the combo meal, otherwise she would never order a combo.
Person 2: But Xander doesn't want to have to sift through different options when ordering a combo! He just wants fries and he'll probably always want fries.

This discussion may have created the two requirements above, but once the requirements have been created, why do we mark each requirement with a persona? I wouldn't code the 'default side' requirement any differently knowing that it is for Xander. What value does retaining the "As Willow" and "As Xander" starts to the requirements once they have been written? What value does the persona give to the one who implements the requirement?

  • seems more like UX question, with the example being specifically defaults vs. settings and the various pros and cons – ratchet freak Jan 8 '13 at 22:08
  • 3
    I've read your post a couple of times, but I don't see a real question in here. Can you make it more specific, with an emphasis on what you're trying to find out? – Robert Harvey Jan 8 '13 at 22:12
  • Couldn't one bump up this question by asking why are you giving names in the first place here? Couldn't you restate the requirements that there should be alternate sides to be shown and the default is to be fries? Whatever argument you give for having the names in the story could likely be extended to future stories, IMO. – JB King Jan 8 '13 at 22:17
  • Are you talking about the value of the developer understanding what's in specific personae, when developing, as opposed to simply the name of the user performing the action? (e.g. Willow fears her spells will go awry, Xander fears he is invisible, and knowing those particular aspects of the personae fundamentally alter the way the developer implements the particular story, rather than just being stand-in names) – jcmeloni Jan 8 '13 at 22:23
  • 1
    @RobertHarvey I've reordered a bit to try to make the question I'm asking more apparent. – ken.ganong Jan 8 '13 at 22:31

It can do, particularly if you're using a BDD / specification framework, such as Cucumber.

In those, you need to write your test cases using Given (And) When (And) Then (And) format. This can be a bit unwieldy when you start writing

Given a user is logged in
And the user has administration rights
And the user is based in the US
And the user has brown hair
And the user is French-speaking
And there is a product available costing less than $80
And the product is less than 5 cubic feet
And the product is less than 15kg
And the user has paged to that product
When the user clicks Add to Basket
Then the product should be added to the user's basket

And maybe you have to write 40 test cases that are all similar. In that case, it is significantly easier to have a known user Xander, who fits the description above, and the product "Buffy the Vampire Slayer Season 7 box set", which also fits the description above, and write the test

Given that Xander is logged in
And has paged to the Buffy the Vampire Slayer Season 7 box set
When the user clicks Add to Basket
Then the product should be added to the user's basket
  • I'll buy this for general discussions, but not for documenting use cases (Xander and Buffy the Vampire Slayer Season 7 Box Set are both too specific). – Robert Harvey Jan 9 '13 at 0:38
  • You've got the community vote and this does give a solid use case for BDD testing. I'm still holding on whether this method of writing behavior would do anything for me as I implement a requirement. Also, glad the top answer got the Buffy reference. – ken.ganong Jan 9 '13 at 16:26

Everything we do in software should be about the user. Design, coding, testing, documentation... Everything goes toward enabling the end user to accomplish their task.

Knowing your users, and knowing for which users a feature is for, is crucial for making good decisions. Your story card is usually not a detailed specification. It should be emough to start a conversation with the product owner, but there are still decisions to be made during development. Knowing your users helps you make those decisions.


Probably the simplest example of personas being important in actual coding is the story "As an Administrator, I must be able to assign security roles to other Users". The unspoken requirement here is that personas other than Administrators must not be able to do this same thing.

Personas, where differentiated, are thus very important in coding, if for no other reason at all than because they identify the persona that can or cannot use the system to perform a certain action.

  • Although I agree with your example being useful, Administrator is a not a persona, it is a role. From agile modeling, "Unlike actors, personas are not roles which people play." and "Personas are different because they describe an archetypical instance of an actor." – ken.ganong Jan 9 '13 at 16:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.