Does the use of personas in Agile have any value during implementation?

Question

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?

Answer 1

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

Answer 2

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.

Answer 3

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.