User Story Modeling

I am an active user of Linkedin. I enjoy participating in the discussions and I try and help people out. I guess it's in my nature as an agile professional to help people remove their obstacles.

Product Owner's Help Desk is one of the groups that I actively participate in. One of the members asked the question "User Stories - in what format?" The most common response, one that I totally agree with, is to use the following template:

"As a [user role / persona / WHO], I want [some feature / WHAT ], so that [ benefit / value / WHY ]"

By following this template you can see what you're going build, who you are going to build it for and why you are going to build it. You can expand on the specific behaviours of a feature by adding acceptance criteria. An example of acceptance criteria might be, "Taxes must me included in the price displayed."

But before I totally get off track I'll circle back to the topic at hand.

User Roles are the WHO in user story template above. My experience as a product owner and working with other product owners has lead me to a technique that helps establish the full audience, or very close to that audience, using your product.

User Role Modeling Technique


  • Brainstorm an initial set of user roles

  • Organize the initial set

  • Consolidate roles

  • Refine the roles

Brainstorming an Initial Set of User Roles

Like most brainstorming it's best to get everyone together that's involved with the product. Gather the customer, product owner, and as many developers as possible. Meet in a room large enough wall space to tape index cards (or sticky notes).

Each participant takes a stack of index cards from a pile in the middle of the group. Later on your can store these User Roles in whatever fashion you like but for right now we'll use index cards for the group exercise. Start with everyone writing role names on the index cards and taping them to the wall.

At this point I would coach everyone to write the user role name to represent a single user. Encourage human based roles instead of ‘company’ or ‘system’ based roles.

As a new user role is created the author tapes the card to the wall says the name of that role. It’s important to note that we are brainstorming and there is no need for discussion or evaluation for any of the roles at this point. The goal is for each person to write as many cards they can. There are no turns, no need to ask for new roles from anyone. Each participant just writes a card as it comes to mind.

Continue until people are struggling to think of new roles. Normally this process takes approximately 15 minutes.

Organizing the Initial Set

After the group has finished create the new roles, we have to organize them. To do this, move the cards around on the wall so that their positions indicate the relationships between the roles. Overlapping roles are positioned as overlapping cards. If the roles overlap a little then the cards overlap a little. If roles completely overlap then completely overlap the cards.

Consolidating Roles

Now that all of the roles have been organized and group, try to consolidate and reduce similar roles.

You can make the job easier by starting with the cards that overlap entirely. The authors of overlapping card describe the meaning behind the role names. After a brief discussion the group decides if the roles are equal. If they’re equal then simplify by combining the roles into one.

In addition to consolidating overlapping roles, it’s also important to discard any role card for roles that are not need for the success of the system.

After consolidating the cards, re-arrange on the wall to show relationships between the roles.

Refining the Roles

Once we’ve consolidated roles and understand how the roles relate to each other. We can model these roles be defining attributes of each role. A role attribute is a fact or bit of useful information about the users who fulfill the role. Any information about the user roles that distinguishes one role from another may be used as a role attribute.

For examples:


  • The frequency with which the user will use the software

  • The user’s level of expertise with the domain

  • The user’s general level of proficiency with computers and software

  • The user’s level of proficiency with the software being developed

  • The user’s goal for using the software. Some users are after convenience, others favor a rich experience, and so on

We can add more attributes by reviewing the software being built to see if there are any attributes that might be useful in describing its users. As you identify interesting attributes for a role, write notes on the role card.

Finishing up

After completing all of those steps hang the role cards in a common area used by the team so they can be used as reminders. I would encourage any team to try this exercise to get appreciation of the users using your software. Understanding our users helps us build better software.

Credit

I have to give full credit of this technique to Mike Cohn. I came across this technique describe here in his book User Stories Applied: For Agile Software Development. It’s a fantastic book definitely worth a read.


comments powered by Disqus