Plan the Backlog

The team needs a ranked backlog so it knows what to do for some time period. The ranked backlog is what’s in the Ready columns on the team’s board. In an iteration-based agile approach, that time period is the iteration duration the team selected. In a flow-based agile approach, the team only needs as much on the board as its WIP limit. The ranked backlog is what the team looks at now. The roadmap provides the longer perspective for the team.

Sometimes your product owner thinks he or she is fully capable of planning the backlog independently, without any input from the team. It’s possible the product owner can do that. It’s more likely, though, that the product owner would benefit from discussing the next set of work with the team.

Here’s a possible structure for the backlog planning meeting:

1. Prepare stories: The product owner prepares stories, preferably on cards that the team can see and handle.
2. Ask for new information: Ask the team about new ideas and issues that arose during the most recent time the team worked. This might be a good time to look at Table 11, ​Possible Improvement Parking Lot​, to see what to address in this backlog. Prepare cards for discussion.
3. Explain each story: The product owner picks up a card and explains it. Ask if anyone has questions about that card. It’s possible that the team wants to discuss acceptance criteria or other stories the team thinks depend on that card.
4. Estimate the work: Once the team understands all the cards, estimate the work if the team uses iterations.
5. Rank the work: The product owner ranks the cards. (See Chapter 7, ​Rank the Work​, for ranking possibilities.)
6. Create the backlog: Add the ranked cards to the Ready column.

There is give and take in this meeting, such as when the team estimates the work. If the team uses ​How Do I Use Planning Poker?​, it might realize this story is actually a feature set. The team might decide to spike the story, to break the story apart into multiple stories, or to go with either the larger or the smaller estimate. The team decides what to do.

There might be give and take in the ranking, too. If the team realizes one story will ease the way for a different story, the team should tell the product owner. Sometimes that discussion prompts the product owner to rerank or even select different work. This is the team’s chance to influence which work it does when. The product owner decides, but the team can influence.