Creating your Initial or First product backlog (Find the Users)

Easy, write down a list of individual features and order them, job done? If only that was the case!

A product backlog is not simply all the product features, it is all the work needed to build and deliver the product. This includes all features, functions, enhancements, and fixes, all that boring engineering work, infrastructure commissioning, documentation and loads more. It is also a planning tool, letting us know what is most important to the business an gives us some indication, along with velocity, when the project is expected to complete.

The secret to a workable valuable product backlog is not to try and do everything at once. Build your backlog in the same way as you expect to build your product, iteratively. Before you even get there though there is some prep work to be done. Sound familiar?

Before you go anywhere, make sure everyone involved has an understanding of the product vision, any known constraints and expectations. For those moving from a less agile environment this is often all contained in the project brief, or sometimes even in a PID.

Approach
The approach we are going to take is broken down into 3 sessions.
1. Find our who our users are
2. Create the initial product backlog
3. Order & Determine the MVP (Minimum Viable Product)

Find out who our users are

In this session we go through a process of identifying our users. Who is expected to interact with the system? Users, Types of users, User Roles, call it what you will, but we need a very good idea on our users. They are after all why we are building the system. We look at:

• Who the users are
• What it is that makes them unique
• What their specific goals and needs are

As with everything agile:

• Make sure you have the right tools
  • Index cards/Large Post-its/Quartered paper stolen from the printer (I prefer paper as it is cheap, readily available, and easy to tear up and bin)
  • A large table/pin-board ( the boardroom table works well here)
• Have the right people
  • The Product Owner
  • At least one other person that has a good understanding of the intended product and how it fits into the rest of the business
  • If you have an analyst on the development team, they should be present
  • Most, if not all of the rest of the intended development team
• Time-box the event
  • 60 Minutes should so it, but take no more than 90 minutes

Right, let’s get going and follow the 8 Steps to identifying your users.
1. Each person writes down all the users/roles that they can think of, one user per card. (take no more than 3-6 minutes)
2. Group them and discard any duplicates. (This is why I favour paper rather than card.)

4. As you go through the cards, again group similar/duplicate users
We should now be somewhere around the 30-40 min mark
5. On the front of each card, again using single words or short sentences, write down

a. Their goals and
b. What they need or want from the system
c. what they provide or feed into the system

6. Now review them

a. Make sure that everyone is happy with the list.
b. Highlight the fact that some key users are missing.
• People like admin users,
• Support
• services
• Senior managers,
• Suppliers,
• Integration partners.
• etc. While they may not all interact with the product in the same way as a day-to-day user may have reporting requirements, budgetary responsibilities, governance requirements, all sorts of things. …

7. Update the list to include them using the same format as the original set. Of users.
8. Stick the cards up on a wall where everyone can see them.

We should now have reached our 60-90 minute session limit.

Ok, now we know who our users are, we know what makes then unique and have some idea what their goals and needs are. Next it is time to start the real work.

Find Part 2 here