I've been in Philadelphia helping a customer with Fit and their planning process. Yesterday I helped them reduce the time they need for their XP planning meeting from two days to two hours. Since they plan with six people every three weeks, I figure I've saved them 182 person-days over the next year. That's not even accounting for the fact that they're bringing more people on board. I think I earned my pay. :-)

If your planning meetings are taking a long time too, perhaps the advice I gave them will help you as well.

As I observed the team plan, I noticed two things. First, they work in a complex domain. They were spending a lot of time just trying to understand what the stories meant. Second, and related, I noticed that the programmers were trying to get most of the details of the stories before making their estimate. Both of these things were reasonable things to do, but they took a long time.

I was also there to help the team start using Fit. Fit is a tool by Ward Cunningham that allows the team to describe the requirements for a story in the form of detailed examples. Those examples are later automatically checked against the software. (I'm involved with the project, too.)

As I describe in my Beyond Story Cards presentation, an agile team should focus on varying levels of requirements detail depending on how close a story is to implementation. When you're planning stories, the appropriate level of detail is just enough to make reasonably-accurate estimates. I asked the team to wait to discuss detailed domain backgrounders later, after the iteration proper had started. Instead, the programmers should just ask questions about those things that would substantially change their estimates. I also asked the whole team to stop extended discussions by asking if they were needed to make the estimate.

Once we were through this hurdle, we still had the problem that the programmers were asking a lot of detailed questions before making their estimates. I reminded them that they only needed information that would substantially change the estimate, but the programmers still seemed concerned about having less than perfect estimates and were asking a lot of questions.

This is something I see a lot and the best cure for it is simply experience with doing planning quickly. Programmers take pride in making accurate estimates and are used to being held over the fire when they're late. So there's an understandable desire for the estimates to be perfect. To go more quickly, though, the programmers needed to let go of that desire for perfection and trust their gut.

I did a several things to to help the group trust their gut. First, I started the meeting by asking each person, in turn, "Do you agree to accept estimates that may be incorrect for this iteration?" Each person said yes, although I could tell that one of the programmers really didn't want to. Second, I listened to the pattern of discussion. I didn't know the group's software or domain, but I could tell when the programmers fell silent for a moment that they probably had enough information to make an estimate. I stopped them at that point and asked for their estimate. I also did so when the conversation seemed to be going a long time or getting stuck on a particular question.

Unsurprisingly, the programmers weren't that comfortable making estimates before all their questions were fully answered. I asked them to do so anyway, using a couple of techniques. I repeated the story and then asked each programmer, quickly, for the first number that popped into their head. I also would ask all of the programmer to take a moment to think, then I quickly went round the circle for their estimate. And later, I asked each programmer to count to three with their fist, rock-paper-scissors style, and then throw out a number of fingers corresponding to their estimate.

After they had estimated a dozen or stories this way, the programmers started getting more confident. They were seeing that their "gut feel" estimates were consistent with each other, even though they weren't talking about them together ahead of time. They started getting more confident, moving quicker, and asking only questions about aspects of the story that could have a big impact on their design.

One thing that I noticed during the session is that when I got involved in side discussions with other folks, the time required to estimate each story started creeping up again. I mentioned this during the debrief: my "menacing" presence and insistence on keeping the estimates moving seemed to be part of why the session took an eigth of the time it normally did. The team laughed and agreed. After discarding the idea of putting a cardboard standup of me in the planning room, they talked about setting a two-minute egg timer and putting stories aside to come back to later if they exceeded the time limit.

In the future, I'm hoping the team will be able to bring the amount of time required for planning down even further, perhaps as low as half an hour. By accumulating a larger backlog of stories (about one release's worth, or six weeks for this team) and by estimating new stories as needed throughout the iteration, they should be able to limit the amount of estimation needed during the planning game. That will allow them to just focus on delivering maximum value for minimum cost, an exercise that's definitely achievable in less than an hour.