Creating the Scrum Product Backlog: Start with the Users!

September 24, 2008 by peterstev

When defining a product, it’s easy to write down list of features and call it the product backlog. It’s much harder to build a product which so deeply and profoundly meets the needs of its users that they just have to buy it. An agile team can use a three workshop process to create the Scrum product backlog. Workshop 1: Identify the users. Workshop 2: Figure out what they want. Workshop 3: define the feature mix which will get you to a product that the customers want as quickly as possible. Let’s start with Workshop 1, the Users.

Workshop 1: Who are the users?

A team of 3 or 4 people brainstorming can identify the potential users of a system very quickly and effectively. The ingredients:

1. At least 2 people who understand the business
2. At least 1 person with technical experience with similar products
3. Desirable: the team who will implement the product
4. A supply of cards or Post-Its
5. A flip chart
6. A pin board

Why should the whole team be present? Doesn’t that cost of lot of money? You are creating information about the product. If the team is present, they will have that information first hand. Otherwise, they will get the information transmitted later. Knowledge is like eggs. It spoils quickly and can (will!) be damaged in transit. And refrigeration costs money too. So it’s better to have them present, if possible.

Step 1: Brainstorm.

Everybody takes 3 to 5 minutes and writes down “users” - 1 user per card. When the time is up, everyone sticks their cards on the flip chart.

Step 2: Discuss.

Each person in the room describes “their” users in one or two sentences: who they are and what each one does or wants. 3 minutes per person should be enough.

Depending on the product you may need to differentiate based on roles or demographics. Continuing the earlier example, Congo Lomarate (CL) wants to optimize its processes and value chain integration. In this case, it is probably sufficient to talk about roles within the various companies, e.g. CL-Operations Staff, CL Operations Staff, Supplier Sales Manager, Supplier Operations Staff, Customer Operations Manager, Customer Sales Staff, and so on.

For a consumer product, the roles may split along demographic lines. For a dating site, users’ needs might depend heavily on sex, age, nationality, country of residence, marital status, sexual orientation, dating preferences, etc.

Sometimes it is useful to consider “extreme” cases: How would a spy find a date? Or a celebrity? What about a single who is HIV+ positive? Although the cases may be too narrow to target explicitly, they may bring out good ideas which are applicable beyond the immediate context.

Step 3: Consolidate and Prioritize

Some cases will be so similar, that don’t need to be considered separately. Group them together as one user.

Which of the users are going to generate or save money for the company? Which users can influence the success or failure of the product? These people may not need much functionality, but if you give them real exciter functions, they can have a deciding influence on the success of the product.

In the case of Congo Lomarate, operational staff at customers and suppliers will be the primary users. But their managers (and probably their executive management) will decide whether to deploy the system, so some good reporting features will help close the deal. The dating site will target people looking for a date, but other users, e.g. advertisers or marketing partners may play a critical role in the success of the system. They need functions, too.

Step 4: Review

Look at the whole. Are you happy with the users you’ve identified? Have you missed anybody? If you haven’t included them already, now is the time to add “administrative” users: The system administrator, support, system developers, Googlebot (a proxy for search engine optimization), etc.

I recently had a project in which discussions about the role of the system administrator lead to a discussion of who will do routine user administration. We discovered that it was possible to make the system largely ‘self-service’, reducing the role of customer support and thereby saving costs.

Administrative users will not earn money directly, but how the system handles their needs can have a substantial impact on the success of the system.

Next Steps

Especially if demographics play a role in your user roles, it may be desirable to create “personae” for each of the roles you consider important. So for a dating site, you might have “Jane, single, 25, attractive, wants to find a long term relationship” or “John, single 18, nerd, is afraid of girls but would like to find a geek chick to hack with.”

Whatever. Find a photo or draw a cartoon, and put the portraits up on the wall so you can identify with them as people.

So in about 2 or 3 hours you have created a list of users for your system and identified their primary objectives. Any surprises? Do you have other strategies? What works for you?

Permalink