Creating the initial backlog is an art, not a science.

Step 1: Brainstorm

This is all about getting out a set – not a prioritized list, just a set – of all the things that you need to do, or may need to do, or could do, to deliver on business needs. Not all of these will have clear requirements, or even have been articulated by the business. In some cases, they’ll be things that the business doesn’t want, but that need to be done in order to deliver on business needs – it’s rare that a business team will prioritize refactoring of existing code, or upgrades to out-of-date software that still works. Getting those things into the backlog is the responsibility of the team.

If the team has an existing “backlog” of some kind (project plan, work list or set of requirements), wait to use this list – to encourage team ownership and creativity, and to find the things that might be missed, it’s best to take the first 10-15 minutes of this process and work from memory. Once the team starts to slow down in generating ideas, introduce the existing list and convert it to additional cards. Similarly, if the team has created a Story Map, wait to introduce that until the first pause in backlog items.

• Everyone needs index cards and markers
• Read the following to the team

We’re generating items for our Product Backlog. This is the list of all the things we need to do to achieve our business outcomes. Some of these will be things that the business has specifically asked for, some will be things that are implied, and some will be things they’d never ask for but we know we need to do. They may even be things that the business wouldn’t prioritize, like updating out-of-date software that still works, because we know that not doing these things will slow us down in the future and make it harder to deliver.

Write down one item per card. Don’t worry about duplicates – we’ll sort that out in a few minutes. This is brainstorming, so all ideas are good ideas right now. We’ll be talking a lot in a few minutes, but for now, let’s work in silence – we want to make sure we get all of the ideas in the room if we can.

Generally speaking, items are best written as active statements – “Upgrade Import System to .NET” rather than “.NET Upgrade for Import System” – because it helps to remind us that we’re doing work rather than having work happen to us.

• Once the team slows down – the “popcorn moment” when there’s a definite shift in activity – introduce any pre-existing lists, to generate more ideas

Step 2: De-duplicate

We need to make one set out of all of the items, so we have something to work with.

• Everyone needs access to tape
• Read the following to the team

Now we need to de-duplicate our items. Let’s move our stories to the wall, and see if we can find any duplicates – it’s okay to keep two things which are related, but we should try to avoid having the same thing twice.

• Once the activity is complete, move on to prioritization

Step 3: Rough Priority

The Product Owner, with help from the team, should rank the items in the backlog into an initial order. This will be updated later as we learn more about items, break them down, and get estimates, but the initial priority tells us which items to work on first in this process, so it’s useful.

For the initial backlog, don’t worry about getting stories into a “ready” state – or even if the things you are putting in to the backlog are truly stories or are tasks. The first priority is to get the list out of all the things that need to be done.