Two Structuring Meetings Patterns

As I describe in my book, it is beneficial to structure meetings (or parts of meetings) to make them more effective. Here are two examples useful for planning meetings, applicable in Scrum and adaptable to other contexts.

Structure: Expose the Options

During a planning meeting, when the overall group energy was low, three individuals were intensely discussing their differing opinions on what to do next. Their debate was so passionate it was easy to lose track and miss the point; even they seemed unsure of each other’s positions. I suggested:

- Only three people are discussing here, the others are bored. Let’s name the options you present, and the whole team will vote and choose the solution.

A team member picked up a pencil and started writing on the board:

1. Let’s do as much of the task as we can and hope to finish it in this sprint.
2. Let’s divide it into smaller items and choose the subset we will definitely complete.
3. Let’s take it to refinement and handle it in the next sprint.

It wasn’t easy to express the intent clearly, and it turned out one person didn’t understand what the other wanted. Engaging the whole team in voting prompted a lively discussion, bringing back group energy. Five people voted for the second option, and two for the third. The decision was made.

What kind of structure can you find here?

When: a group or just a few people are discussing intensely
Then:

1. Notice that not everyone is engaged or that the decision is far from being made.
2. Ask for naming the options (ideally write them where everyone can see).
3. Vote on the options (similar to a planning poker game).
4. If there is a draw, select an option by drawing lots or any other method.

Structure: Structuring Planning Meetings

When a particular type of meeting tends to be chaotic, introducing structure can help organize it. In Scrum Planning meetings, I like to separate steps in the planning process (a few selected steps):

1. The team browses items that:
       a) have been recently refined
       b) weren’t finished in the last sprint
       c) are at the top of the backlog
   Browsing means briefly reminding everyone of the item’s intention without going into details.
2. Product Owner, supported by the team, prioritizes (explaining why) and selects items that are strong candidates for the current sprint. Often, this means removing weaker candidates.
   This prevents discussing items that won’t be developed in the sprint.
3. Starting with the highest priority item, Product Owner presents (or reminds) acceptance criteria for the item and the team estimates it (assuming items are refined enough to be estimated). This is also the time to delve into details if necessary.
   Alternative: Product Owner presents all items one by one, then the team has time to brush design and make estimations.
4. Team chooses how many items they can take on to make a reliable commitment.

No matter what structure you use, keep the boundaries of steps clear—especially avoid discussing details too early (or possibly not at all).

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)