Refining Your Scrum Planning Meetings
Every so often I’ll hear someone say that Scrum has “too many meetings,” in particular, too many planning meetings. Planning is how the team—including the product owner—builds and understands the common vision for the product as well as the tradeoffs that help make delivery sustainable. Planning is a good thing, and meeting isn’t a bad thing. But planning meetings, such as the sprint planning meeting and supplementary refinement meetings, are ineffective without the appropriate context and approach.
When I teach about Scrum, I contrast Scrum events with meetings in that Scrum events are opportunities to collaborate, as opposed to simply times to meet. Scrum meetings are about sharing information with the goal of identifying actionable steps. A sprint planning meeting, for instance, that is interactive and collaborative gives the team an opportunity to understand and validate requirements, do basic design, estimate work, and become engaged in the product process.
If you find your planning meetings becoming passive events where no one is asking questions or actively seeking to understand the backlog, the problem might be in either the execution or the preparation.
If the team isn’t participating actively in planning or refinement sessions, consider how the meeting is being facilitated. Encourage participation through basic facilitation, or by using techniques such as planning poker to make estimation more engaging and to provide a bit more safety for everyone to speak.
Planning and refinement, like all successful meetings, require preparation. In the case of a planning meeting, this means having a reasonably well-defined backlog so that the team can estimate effectively, as well as ensuring that the time allocated for the meeting is sufficient for the team to participate. Don’t discuss user stories in a planning meeting unless they have met some basic criteria. Preparing backlog items with a reasonable amount of clarity and detail will help ensure that the team can ask useful questions and feel like the planning meeting is a good use of their time.
A rushed planning meeting can also be a disengaging one. Allocate enough time so that the team can review, discuss, and estimate each story. In sprint planning, make sure the team has time to discuss upcoming work.
The events in the Scrum framework are meant to be productive collaboration events that replace more passive, wasteful meetings. Agile planning processes provide an opportunity for engineers to participate in the definition and scope of a product, and it’s important to remember that few, if any, other approaches ask for the advice and consent of those building a system before setting things in motion. The output of planning is supposed to be a plan to accomplish work that the team agrees to.
If this is not what you are seeing, and your Scrum meetings seem more chore than choice or more burden than benefit, realize that you can do better. Don’t just complain—figure out what to change.
