In my travels I spend a good deal of my time discussing Scrum Product Ownership, Product Backlogs, and inevitably User Stories. Stories are containers or artifacts, which have nearly become ubiquitous for handling software requirements within agile teams.

Most seem to be a using the standard phrasing construct for his or her stories:

As a – User

I want – Feature or Functionality

So that – Business why, What problem does it solve?

Because the “User” clause is so simple, I see many teams who fill out their user stories in a by-rote fashion. They’ll literally have hundreds and hundreds of user stories, features, themes, and epics and all of them have “User” as the user.

I think they’re missing a wonderful opportunity to make their user stories, well, more usable and more customer-centric. That’s where I want to go in this article.

The “User”

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.

A Story

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 J

Persona’s

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.

Wrapping up

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’m Bob

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:

  • Envisioned
  • Prioritized
  • Designed
  • Built
  • Tested
  • 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,

Bob.

References

1 Comment