Filling the Product Backlog: Go For Excitement

October 1, 2008 by Peter Stevens

Picture courtesy of jakuza@Flickr

Once you know who you are building the product for, the next step is to create a list of features which will excite your customers and get them to use and buy one of your products. Which functions should you put into the system, and why? The user story workshop creates the initial product backlog.

This workshop is similar to the last workshop where you identified the users and buyers of your systems. This workshop needs the same people, except that the importance of the development team rises as you get closer to implementation. It is also desirable to have some real users represented. The workshop structure structure is simple:

1. Review the format of User Stories and the Kano Model.
2. For each Role,
1. Identify the main goals
2. Identify the functions which that person wants the system to perform to achieve those goals
3. Decide on next steps: Homework or Implementation

User Stories

A user story follows the form:

As <type of user>, <function> so that I can achieve <some-goal>

A user story emphasizes the user and his goal. The function is merely means to an end. A user story can be prioritized based on how important the user is to the success of the system and how important to goal is to the user and the function to the goal.

What makes a good user story? The INVEST model gives clear guidelines. In this workshop, most people start with high level “goal” stories and refine them down to smaller stories which are easily understood, implemented and tested by developers.

Kano Model of Customer Satisfaction

According to Kano, there are three classes of features:

1. Prerequisites. If your product doesn’t have these features, it will immediately be removed from consideration. Who wants a house without a bathroom?
2. Linear Features. The more the better, but their higher the cost. A family that wants three bedrooms will not consider a house with one, but they might consider a house with 2 or 4 bedrooms.
3. Exciters. Unique features which only this product has and which convince the customer to say ‘Yes! I want it! This one and no other!”

So as you create stories and as you implement the product, you need to ensure you’ve got enough of the prerequisites to keep the customers from jumping off and enough exciters so that the customers buy the product.

Identify the users goals

Now that you and your team are focused on what you are trying to accomplish, let’s get to it! Let’s create a list of features which will excite your buyers and users.

Now for each role identified in the previous workshop, identify what s/he wants to accomplish. Let’s say we identified the following users for our dating site: John, an 18 year old geek and Jane, a 25 year old women looking for a long term relationship. What might they want?

• As John, I want to find women whose interests match my own so I can find an activity partner.
• As Jane, I want to judge whether a potential date is trustworthy before I reveal my identity.

When you are formulating a user story, you may drop the goal part if it is obvious or clearly in the context of a larger goal.

Create a list of stories

Then brainstorm on the functions to achieve those goals. The first purpose of brainstorming is to identify ideas, not qualify them or discard them. A good method for brainstorming is the “cards, present and consolidate” method:

1. Everyone individually writes down user stories on cards, one user story per card. Time box this to 3 minutes.
2. Each person in turn presents their stories to the group and posts them on the pin board.
3. After presenting all the stories, consolidate those which overlap too much to merit separate treatment and eliminate any others which are considered unimportant.

John’s goal will lead to stories for entering and searching for common interests and other common ground. Jane’s goal may lead to a recommendation system like LinkedIn or a voting system like dzone. For example:

1. As John, I can enter interests about myself so others can find me
2. As John, I can create interest-tags for myself so others can find a better description of who I am
3. As John, I can search based on interests, including self-defined tags
4. As Jane, I can find out if any of my friends have dated this person, so I can check references
5. As Jane, I can review and score a date, so I can warn others about losers

Some new roles may occur to you during the brainstorming. What about Sam (a 40 year old married man in a midlife crisis) or Sandra (a 35 year old neglected housewife)? Each wants to find a partner for a secret relationship. Sam and Sandra’s goal will probably provoke some intensive discussions about the purpose of the site. I prefer not to waste time arguing about controversial points. I just add them to the list of roles and worry about whether to include the role later.

Next Steps

Once you have handled the most important roles, you have a feature list which can become the product backlog. You might need more than one workshop to handle all the important roles, but basically, you could start prioritizing, estimating and implementing.

You could also say, “We haven’t talked to any users or customers yet. Maybe we should.” Or maybe you feel you have more homework to do.” Scrum and XP encourage you to move quickly to implementing functionality and use demonstrations to get feedback. But there are alternatives. What would you do at this point?

Permalink