Implementing Personas in an Agile World – Tips For Better Story Telling

When working with organizations with a legacy of writing formalized requirements but moving to agile development, one of the first items to approach is the use of user stories as a way of articulating the work which will comprise their product backlog. As a Coach, I diligently outline Rachel Davies’ popular template:

As < persona >, I can < what? > so that < why? >

We then explain that the user story isn’t complete until the details and acceptance criteria are more well defined beyond the initial sentence. But what often gets missed in the conversation is the elaboration of the persona concept. So, when I ask the team to write their first story, I often get something like this:

As the claims adjudication system, I need to have the value of in-network provider set to “1” so that the value of in-network is “1”.

After some discussion, I trace this behavior back to years of articulating requirements as “The system shall indicate if the provider is in-network.” This has been so ingrained in the team that they do not see the users or benefits derived from the system functionality.

It is 2019, not 2001: A Space Odyssey

As a Coach, I then (in an encouraging way) ask “Do we really think the claims adjudication system needs something? Unless our claims system is housed on the HAL9000 from 2001 (and even then) the system probably doesn’t need anything.”

After some discussion and cajoling on my part, we often end up with something like this:

As a subscriber of a PPO plan, I need for my provider to be identified as in-network so that any negotiated discounts are reflected on the explanation of benefits.

I then go on to explain their whole setting value to “1” is part of the acceptance criteria, which can be validated as part of the Product Owner’s approval of the story. This is a good start, but just scratching the surface of the journey the team is about to begin.
5 Whys? Because we Like You!

I then switch gears to use the “5 Whys” technique, that was originally developed by Sakichi Toyoda and was used within the Toyota Motor Corporation during the evolution of its manufacturing methodologies. Often this process is as pleasant as a wisdom tooth extraction. It often takes on the attributes of the metaphor of “pulling teeth” as you have to work with the teams to ask questions. We first ask the question of who is actually seeing value from the interaction described in the story:

Who has an interest if the services are delivered are in-network or out-of-network?

The Subscriber

Then we move to the 5 Whys:

Why?

If they visit a provide who is in-network, any negotiated discounts are applied.

Why?

Subscribers often pay more for their premiums to have reduced out-of-pocket costs if they stay in network

Why?

Deductibles are usually half the level of out-of-network provider

Why?

Subscribers often only pay a minimal co-payment for in-network providers

Why?

Doctors and other providers want access to our members as a source of clientele so they will negotiate discounted rates.

When used effectively, it helps the team understand the underlying reason “the system” has been designed to function and manage the claims data in a way that supports the organizational business model. As a Coach I exercise caution when applying this technique. In some instances, the situation lends itself to this iterative interrogative technique. However, I have also observed team members become frustrated and exclaim “I don’t know why, that is why we hired a coach, to help us figure this stuff out!”

The” What About…” Paradigm

So now that we have one story in the pipeline and we better understand it based on the 5 why responses, I can ask the question “So is every subscriber the same?”. In traditional organizations, this is where the Business Analysts step in with what I term the “what about…” paradigm. They immediately jump on the initial story and the conversation around the Scrum Board begins:

What about subscribers in Ohio versus Florida?

What about Traditional PPO versus High Deductible PPO?

What about someone under 18 versus someone over 18?

What if they are under 18, but are an emancipated minor? (I had to look that one up…)

In some cases, when we look at the acceptance criteria, these “what abouts” are accounted for. Especially when using the “Given – When – Then” format.

Given the subscriber lives in Ohio, When the subscriber is searching for an in-network provider, Then verify access to OH Network provider list

I have seen 20 “Given – When – Thens” on the acceptance criteria of a single Story. As a Coach, I then often (rightfully) zero in on using acceptance criteria as a way to split stories. But this also provides the chance to espouse the merits of personas as a way to capture the items formerly baked into overly elaborate acceptance criteria.
Stumbling into Personas

At this point we have (intentionally) stumbled into the discussion of the first part of the story, the persona.

Strictly speaking, sources like Agile Alliance will take a hard line and say that “Personas should not be confused with other conceptual tools used in defining software requirements… “user roles” (such as sales person, administrator, etc.) or “market segments” (such as “18-25s who exercise”). “

From a practical-in-the-trenches standpoint, I believe whatever gets people to deconstruct the general term of “user”, “system”, “member”, “client” or “subscriber” to a more defined role adds value. In this way the stories provide a more compelling look at the attributes of the system the team is implementing. This technique has also worked to set Product Owner expectations and allow for more informed prioritization of the work in the backlog.

I now start seeing stories like this:

As a as an emancipated minor with a PPO plan in Florida, I need to utilize the iPhone-based app to validate that my policy is still active so that I can utilize the in-network providers in my region.

In this case, as it was explained to me, the “system” needs to exercise business rules to ensure that even though the emancipated minor did not pay for the renewal of the plan, they can validate that they are covered by their parents plan and should be able to validate the fact that they have access to in-network providers on their Florida-based PPO plan when accessing the data securely from an iPhone.

Sometimes it is Fun… Sometimes it Just Needs to be Done

Finally, some purists will say you need to have a visual with a stock photograph, a name and social or professional details: “Max Minor, is an emancipated minor who is 17 years old living in Florida who enjoys surfing and plans to be a Bioinformatics major in College.”

But, again my experience from the field, is that some traditional organizations askew this approach. They are typically the teams which refuse to name their Scrum team anything other than “Team 2.” In this case, while the “by the book” persona is definitely more fun (and arguably valuable), I find it acceptable if the team goes with the longer descriptor in the persona section of story. I have seen that it is more comforting for people moving from other requirements management techniques to stories, to retain the level detail formerly housed in the something like a Use Case with alternative flows. In this case, I generally choose my battles and if the team accepts the concept of personas, I can live with the fact that they have not created a persona for Florence the Florida HMO subscriber who is a single mother of 3 living in Coral Gables, Florida and working as a stenographer.

Moving traditional teams who have relied on “the system shall” statements (as they say) is a journey. As a Coach, ScrumMaster or Product Owner it is our role to bring teams around to the merits of not just implementing User Stories because the “Scrum-Gods” say so; instead I stress the concept that they provide measurable value. They are integral to the quality, predictability and success of the team. The same way teams will normalize on their Sprint velocity, they will also stabilize on their user stories and by extension their personas. Personas will help teams to validate subtle differences in the required behavior of the systems they support, and they answer those pesky Business Analysts’ “what about…” questions.