I consider the user clause in the user story to be a “mini persona”. I’m not a UX expert, but to me a user persona is a description of a user, or better yet, one of your customers. It gives sufficient background on them, their experience level, their perspective, and their problem space, that it helps someone to “visualize” the specific customer.
From a software perspective it helps with all aspects of software delivery. Most importantly it helps us in creating the customers experience in I using our products.
In 2009 I joined a company that was implementing Scrum to deliver an email marketing, SaaS product. The company’s name was iContact and if you’ve followed my writing, you’ve probably heard about them before. When I first joined, I had a fast paced challenge to ramp up quickly.
Sometime in my first few days, I overheard a couple of Scrum team members talking. As I got closer, they seemed to be talking about me – Bob.
One of them said – It’s not clear to me whether Bob would approve of the design of this feature. It assumes an awful lot of application knowledge when setting up the report template.
Another replied – I think Bob is a bit smarter than you’re giving him credit for. Sure, he’s managing a small business and is overloaded with everything that is involved in that. But he’s a 40-something, college grad, with solid technology and computer skills. Point is – I think he’ll be able to quickly “figure it out”.
Still another replied – I disagree. Bob is not that smart and I believe he’s more technology phobic than literate. Remember, he had to call Geek Squad to install and setup his computer system. He’s fairly clueless, so we’ll need to make it more intuitive.
At this point, I wanted to interrupt their conversation and set the record straight that (a) I certainly wasn’t clueless, (b) I wasn’t technology phobic, and (c) that I didn’t appreciate them talking about me in the hallways.
But then it dawned on me that they weren’t talking about me. Whew! They were talking about the customer Bob, or actually our persona of a customer which we named Bob. I was incredibly glad that I didn’t embarrass myself
My story actually helps define a great deal of the intent behind develop customer persona’s within your design teams and then sharing it across your agile teams. It helps the team to start to understand the customer. By giving them just enough information to put themselves “into” the customers’ perspective.
In this case, one of our personas was named Bob. Bob had a particular profile with respect to his background and needs for the Small-Medium sized Business eMail marketing tool we had built at iContact.
What was even more exciting was the fact that the team was talking about Bob as if he was real. And they were actively considering him, his unique perspective, and his needs for the system as they built out new features. That’s exactly the point of developing the personas in the first place.
There were Five
In our case Bob wasn’t alone. We had developed a set of five personas to represent key aspects of our customer base. For example, one of the personas was very well educated and the other had a high school diploma. One of the personas was relatively comfortable with computers and technology and one of them was not—being simply a storekeeper trying to “dip their toe” into email marketing.
We hung printouts of the personas all over the place to remind everyone of “who” are customers were and “who” were building our products for. That’s another reason that conversation was going on, we had had socialized our personas so well that they became almost real people.
Not just for design
And the personas didn’t simply stop at design. For example, our testers found them incredibly useful in determining what and how to test. We were constantly using risk-based testing techniques and prioritizing our testing. When decisions on what, how and when to test were being mad, we often examined the personas—knowing that we had to keep our customers “whole” as a part of our testing efforts.
Here’s a wonderful article that speaks to this aspect of persona development.
So instead of stories that all looked like this:
As a – User
I want – Feature or Functionality
So that – Business why, What problem does it solve?
We had stories that looked like this:
I want – Feature or Functionality
So that – I can achieve very specific goals for my business
As well as stories for Jane, Todd, Beatrice, and Sam.
You might think that it doesn’t make a difference. But I found that “putting on the hat of the customer” makes a great deal of difference in how we:
- and Deployed
Our products. In the end, it’s ALL about the customer. And while we say that, personas make it much easier to envision who they really are.
Stay agile my friends,
Don't forget to leave your comments below.
- You can get a free PDF copy of my book Scrum Product Ownership by joining my mailing list at rgalen.com In it, I discuss User Stories in the context of the PO role.
- Article on 7 Core Ideas about Personas
- Overview of personas, including an example
- Personality in Design - some examples of well crafted personas
- Personas as a means of focusing your testing