Why we meet

Dwight D. Eisenhower once said, “In preparation for battle I have always found that plans are useless, but planning is indispensable.”

The quotation seems to describe a contradiction with which all agile teams should get comfortable. On one hand, planning is critical to success. Planning allows us to organize and prepare for the future. On the other hand, when development starts, things can quickly change and the plan no longer applies. The fact that we go through a planning process increases the chances we will succeed, even if the resulting plan gets changed. This is why built-in feedback loops are so important in scrum.

There are too many meetings!

This comment from team members is common, but is (almost) never an indicator that the team is meeting too much. Scrum requires only a fifteen-minute meeting each day plus a half-day at the start and finish of each iteration (and frequently less than that!). Let’s examine some possible reasons that people feel like there are too many meetings.

First, the Scrum adoption started outside the teams. The teams have been told that they will do Scrum by corporate edict. A natural reaction to an order from above is to express annoyance at everything associated with that order.

Second, it is possible that Scrum ceremonies could look like a lot of meetings to a team that had no process at all. However, it is not likely that a team had been consistently delivering any work products if it had less process than Scrum.

Third, the perception of Scrum's overhead might stem from the cost of iterating every two weeks. The need to periodically drive the software to a shippable state feels like needless overhead to some individuals. On the other hand, most other processes lead to late products that miss on fully meeting business needs.

Fourth, people who believe Scrum is a lot of overhead may not fully understand it. They may see the new things they have to do (daily stand-up, iteration planning, iteration review, and retrospective). In the early stages, it is difficult to see the benefits of Scrum, such as greater visibility into progress, closer contact with users, as well as earlier coordination and greater communication with coworkers to ensure all team members are heading in the same direction.

Finally, if Scrum feels like it has too much overhead, it is probably being done incorrectly. When done right, Scrum is lightweight, management needs are small, and it doesn’t take much time away from coding. A perceptive Scrum Master will hear complaints as a warning signal and investigate to determine the true source of the problem. Luckily, it is entirely up to the team how effective a meeting will be.

Iteration planning

In Scrum, Iteration Planning is the meeting where the team defines the goals of the Sprint. In the first half, the Product Owner (PO) presents the priorities for the iteration and the team discusses each item. The team can ask the PO to clarify requirements and unpack any assumptions. The second half of the meeting (“planning”) is for the development team to discuss a high-level technical approach, identify the tasks involved in completing the stories, and commit to the stories they are accepting in the iteration backlog. At this point, the PO can choose to re-prioritize work to get the most business value based on team capacity. Everyone is expected to provide input and everyone’s voice is taken into account when determining the actual level of effort. This is the most intense of the Scrum ceremonies, but in a few hours, the team is ready to begin developing against the highest priority work.

When done correctly, iteration planning is an important factor in the success of the team:

Whole team should be involved. If this is done as a team, there is buy-in and shared commitment for the work to be done during the iteration.
Product Owner has insight into the technical aspects of what is involved. Even if they don’t understand the details, they gain an appreciation for the amount and complexity of the work to be done.
Conversations should give substance to vaguely worded stories up-front, enabling developers to develop the right thing the first time.
Everyone is communicating from the beginning. This sets the tone for the whole spirit of Agile/Scrum. Teams develop cohesion without barriers based on title or job descriptions.