The Big Wall: Prioritizing and Estimating Large Backlogs

You’ve just finished a great story-writing workshop with your stakeholders. You’re excited about the new product and are anxious to get started. Until, that is, you get back to your office and look at the mountain of stories that you’ve somehow got to estimate and prioritize. All your excitement disappears as you face the hard truth: You have no idea where to start.

The sheer size of new product backlogs can be overwhelming. That’s why you need to attack them with something even bigger. I’m talking about a club that’s about 14 feet wide and 10 feet high. You need to find yourself a big wall.

While planning poker is a fantastic tool for estimating user stories, it’s difficult to imagine tackling a pile of hundreds of stories, one at a time. That’s why I use a technique I call The Big Wall. It’s similar to Lowell Lindstrom’s Affinity Estimation, which I was introduced to in 2008, with one distinct difference: The Big Wall technique allows you to consider both size and priority.

The only tools you need are a stack of user stories (get them from your product owner, or if you are the product owner, print them) and a big empty wall, about 14 feet long by 8 to 10 feet high. Then you need to gather your stakeholders and team and plan to spend a day or so getting physically involved with your stories.
If you already have an estimated backlog, you can just do the prioritization section of this exercise. If your product owners and stakeholders have already given you a prioritized backlog, you can just do the estimation section of this exercise. (Your product owner will likely want to revisit the prioritization after the estimates are done. After all, cost has a big impact on priority.) Let’s look in detail at how this would work, beginning with the team’s role.

Team

Given a raw product backlog, you should start with estimation. Instruct the team that the far left of the wall should hold the smallest possible stories, and the far right should contain the biggest possible stories, without regard to numbers. Then ask team members to put stories somewhere on the wall based on those two poles. The advantage to doing it this way is that there is no preconceived notion of what a two- or three-point story is; it’s truly relative based on how big the wall is, which is why it’s nice to have a really big wall.

Stakeholders

Your customers and stakeholders will look at the stories in a much different way than the team just did. They’re not as interested in how many points a story has; they are most interested in finding the stories that relate to them and making sure those stories get done. This may put the stakeholders in conflict with one another. This is OK, in fact, it’s ideal because it reflects reality and helps the product owner make tough decisions.

The first thing I do is explain to the stakeholders why we are here and what we want to accomplish. This little speech goes something like this: “I have met with each of you and have created a set of stories that reflect your wants and needs. The team has spent the morning grouping these into relative sizes. The stories to the left are smallest. The stories to the right are the largest. What I’d like you to help me do is determine the relative priority of all these stories. I’m going to ask you to move these stories up or down inside the taped lines. The higher up a story is on the wall, the higher its priority to the business. If you place a story at the top, I will ask you for justification as to why it’s up there. You may also ask each other why one story is more important than the other. In the end, we’ll know how all the stories relate and have an idea of what functionality we’ll have early in the project and what functionality will happen later. The team will observe and might ask questions to help them better understand a story.”

Remind the stakeholders that if they move a story lower on the wall than someone else did, they need to mark it with a yellow dot. This alerts everyone that we might need to have a conversation about the story’s true priority. I also encourage/expect people to ask, “Who moved this one down (or up)?” or to say aloud, “I think this one needs to move. Who wants to disagree?” This enables a conversation to happen between the interested parties without facilitation. If a discussion goes on too long without resolution, the facilitator (usually the product owner), should collect the card, note the two stakeholders who cannot agree, and make a note to meet with them privately later.

While the team is in the room for this exercise, they are not active participants. They are observers, taking notes on the behavior, the interactions, and the reasons why certain stories are rising or falling in priority. They can also answer any stakeholder questions, if needed. If there are stories that the team couldn’t size with confidence because it required answers from a particular stakeholder, the team can also ask questions about those stories, as time allows.
The goal of prioritizing as a group is to help all stakeholders understand the priorities of various stories and how the others view it. The exercise should take between two and six hours, depending on the number of stories and the number of stakeholders.

By the time you are finished, the stakeholders will be able to see the start of a release plan. If you know the team’s historical velocity, you can even give them a rough range of which stories in the upper-left quadrant will be finished. For more information, see Chapter 4, “Determining Team Velocity,” and Chapter 11, “Release Planning” in my book, The Scrum Field Guide: Agile Advice for your First Year and Beyond.