Know Your Users
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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)