Agile Zone is brought to you in partnership with:

Chris Spagnuolo has been working in the Geographic Information Systems (GIS) field for nearly 15 years. If it involves GIS, he's probably done it...everything from field data collection to large scale enterprise GIS deployments. Through this experience, he has reached the conclusion that the most effective way to deliver value is by the implementation of agile practices. He believes strongly in the effectiveness of agile practices and he is leading a new group to evangelize the benefits of agile. Chris is a DZone MVB and is not an employee of DZone and has posted 29 posts at DZone. You can read more from them at their website. View Full User Profile

Know Your Users

  • submit to reddit

In agile software development, we create user stories as a way to communicate the requirements of our users in an easy to understand format. Usually, they take the following form:

“As a <user type>, I want to <function> so that I can <business value>.”

An example of a real user story looks like this:

“As a frequent traveler, I want to rebook a past trip so that I can save time booking trips.”

Good. Now we have a simple story to put into our backlog. But what I’m curious about is, just who are these user types…these frequent travelers? We often give them generic names like product owner, frequent traveler, end user, customer, or just the user. There’s no meat on the bones of these generic user types. They have no personality. I firmly believe that as developers we need to focus intensely on our users and what they want if we want to create remarkable software and products. So if we focus so intently on our users in our marketing efforts and in our sales cycles, why do we make them an amorphous lump in our user stories? Why don’t we know more about them? Ultimately, we’re developing software for them. Shouldn’t we know them a little better?

Well, here’s a suggestion: Stop using generic user types and use personas instead. Give your users some life. Real lives. Consider creating an actor table to define the personas of each user type. It will connect you more with your end users and really help your delivery team focus on developing software that doesn’t speak to the generic masses. Here’s an example of an actor table for one user persona:

If you create a persona for each one of your user types and start using their names in your user stories, you’ll start feeling more connected to your users. They won’t be a generic mass out there anymore. You’ll be developing software for somebody. You’ll start caring about what you develop and in the end this will improve your software and ultimately improve the satisfaction of your frequent traveler user type…or let’s just call him Jeff.

Published at DZone with permission of Chris Spagnuolo, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Sindy Loreal replied on Sat, 2012/02/25 - 11:05am

We have a list of industry specific personas that are updated by our research and marketing departments. We also have a list of internal personas to help capture any internal admin features that might be required. It’s a little time consuming to go through each persona, but the feedback at the end of a requirement gathering session is generally positive as we seem to cover all bases.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.