I was just working with a client in their first month of Agile development. They're transitioning from an ad-hoc process (code-and-fix) to Agile, and so they're adding a lot more ceremony than they used to have. One of the developers was complaining about all of the extra meetings - a half-day to plan an iteration, a half day at the end to do a demo, review, and retrospective, and another half-day for release planning. He said, "I keep thinking about how much code I could get written in 4 hours".

If your meetings are taking longer than you'd like, and people are getting antsy, you may want to look at ways to speed them up. One well-optimized team I worked with can do a demo and review of a 2-week iteration in an hour, take a break, and then plan their next iteration in an hour. (They do a longer retrospective every month or so).

In her new book, Collaboration Explained, my colleague Jean Tabaka suggests that you should plan on two days of planning for every day of effective meeting. Meetings are expensive; an all-day team meeting costs thousands of dollars. One or two people (product managers, analysts, leads, or ScrumMaster) should do a fair amount of preparation to ensure that your agile meetings are as effective as possible.

Iteration Planning

An Iteration Planning Meeting is all about agreeing as a team that we can deliver a certain amount of work within the upcoming iteration, and figuring out how to go about implementing that work. For me, the most important part of a successful IPM is that the whole team agrees on what is to be built, right down to detailed acceptance criteria for each story. This part of the meeting goes a lot faster if you've done some of the following:

1. The Product Owner comes in with a prioritized list of user stories to be built
2. The team, or at least a few members, know what's at the top of the list
3. The Product Owner has done a first pass at writing acceptance criteria for the stories
4. The Product Owner and a tester have discussed those stories and added negative tests (edge cases)
5. The tech lead has looked at the stories and acceptance criteria, and discussed these with the Product Owner
6. The team got the list of stories a few days before, so they've had some time to think about implementation

If you extend "learning about requirements" over the days leading up to the IPM, the meeting becomes more about confirming expectations and committing to an iteration - these are the activities that really require the whole team to be together. If you're automating Fit acceptance tests, sometimes testers, analysts, and the product owner can work together to create tests just prior to the IPM, to speed things even more.

Tasking and estimation can also take a long time, especially with a large (12+ member) team. Smaller teams can task more quickly. One team I worked with liked to have a more informal session in the morning of the iteration planning day, where pairs of developers each took several stories and tasked and estimated them in the team room, talking with analysts, testers, and the product owner as needed. In the afternoon, each pair presented stories and tasks to the group, and the "formal" meeting was over in an hour or two.

Some teams skip tasking in the IPM altogether, instead relying on just-in-time tasking during the iteration. This approach works well for stable, experienced collocated teams who estimate stories in terms of story points. If your established team got 53 points worth of stories done in the previous iteration, you'll probably get about 53 points done this iteration, so detailed task planning is not needed to form the basis for an iteration commitment.

Additional Reading:Shorter Meetings Part 2: Release Planning.