Know Your Users

Post written by Chris Spagnuolo. Follow Chris on Twitter 6 comments

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.

Share on Facebook
Post to Google Buzz
Bookmark this on Yahoo Bookmark
Share on FriendFeed
Bookmark this on Digg
Share on reddit
Share on LinkedIn
Share on StumbleUpon
Bookmark this on Delicious

  1. Audrey Troutt said,

    At my company we realize what a difference it can make to have a specific person in mind when making development decisions, but how real should these people be? Since my teams tend to work very closely with our clients and sometimes have easy access to the end users it is easy to have a real person in mind when we craft a story. What do you think about using real people instead of fictional personas? We encountered a problem with this when one of our projects grew from custom software for a small dedicated user base to a publicly offered application; some of the design decisions we made obviously needed to be reconsidered. Do you think we could avoid that by always developing more generalized personas?

  2. Matt Rowe said,

    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.

  3. Mateus Bonadiman said,

    Good question and answers so far…
    In my point of view, having real or generic user types in your stories doesn’t help too much if your team doesn’t have a good picture of what are the purposes of your business and the product itself. My point is, the P.O. (and management) should be aware of this issue and work together with the SM and Team to make sure everybody knows what is the goal the product they are developing. Having real users on your stories could also help, but it’s not enough. Acknowledgment of your market by whole organization in the key point here.

  4. Siobhan Walsh said,

    The best example I have heard of in terms of understanding users is a US law firm who go out and observe users at work during the spec development stage. People are rarely good at explaining exactly how they use anything – including software, partly because much ofthe processe we use become quite sub-consious and as such processes can be lost in the telling.

    By watching users at work, the IT team developed a real understanding of how software was used in practice as opposed to in theory, could talk to users about why they used products in certain ways and understand first-hand the difficulties that current solutions threw up.

    As a result of this software could be designed with the user as central to the process, which, more often than not, meant that the end customer was ther in the centre with them.

  5. Chris said,

    @Mateus B: I agree completely. A PO and a team need a vision and a roadmap to keep the delivery team focused. But, I believe that adding personas and using them in user stories keeps a team focused on not just the vision and goals, but the customer as well. Customer satisfaction is everything in my book, so anything we can do to improve improve customer satisfaction, including making our user stories more personal, is a good thing to me.

  6. Martha said,

    As a technical writer and usability person (not a developer), I’ve often been charged with researching and developing personas (user archetypes) for products. I usually provide information about a primary, secondary, and tertiary persona.

    The idea is that no product meets the needs of everyone, but it should meet all the needs of the primary persona, most of the needs of the secondary, and some of the needs of the tertiary.

    To make the personas easy to understand and realistic, I developed a template that worked out well. It usually included some or all of the following information:
    - Name
    - Description
    - Job title
    - Job tasks
    - Computer knowledge
    - Motivations
    - Frustrations
    - Needs

    Here’s an example of a persona for an education Website I helped design:
    Name and Title: John, Software Engineer

    John works as a software engineer, something he’s been doing for 15 years. He makes good money, but he feels he’s burning out. He thinks he’d make a great project manager, but no one takes him seriously, not without a business degree.

    His work life is pretty overwhelming. He goes to work early and leaves late to meet unrealistic deadlines. In fact, he often fantasizes about what he’d do if he were a manager – either change the management style of the company completely or go to work for someone else! His wife, Monica, totally supports his desire to get an M.B.A. She knows he’d be a lot happier managing projects, rather than writing software.

    John can’t afford to spend a lot of time getting the M.B.A., especially with his hectic work schedule. But he’s willing to do it if it doesn’t take too long. He knows that getting an M.B.A. would increase his income and increase the time he could spend with his wife. Plus, he’d make a real difference in the software world by implementing some of the processes he’s developed over the years. All he needs is that M.B.A. That’s why he’s looking at HEC.

    * Promotion.
    * Professional development.
    * Greater salary.
    * More respect from his peers.

    * Taking classes around a hectic work schedule.
    * Wondering if the instructors will really know what they’re talking about.
    * Can’t spend years on a long-term degree program – needs the degree and professional development now!

    * Wants classes to help him in his immediate career.
    * Wants classes taught by professionals who have real-life experience.
    * Wants to make some contacts with other executives or upper-level managers for possible job networking.
    * Wants classes that can be taken at night, online, or on the weekends, so he can keep working.

Add A Comment


Creative Commons License
©2011 Edgehopper.com. Please don't copy me, it's bad karma.
Edgehopper by Chris Spagnuolo is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.