Back in Part 1 of this series, I explained all the problems I saw with this interview question:
“The product owner and dev team cannot decide on a sprint goal, even after hours of discussion. They (the team) feel that the tasks for the sprint are too varied to manage to a single sprint goal. What should the Scrum Master do?”
My final problem was this: Why did anyone allow hours of discussion? Why didn't someone, such as a Scrum Master, stop the discussion with some facilitation technique?
I suspect that's because most people don't know their facilitation options. While there are plenty of facilitation options, here are just three I'll discuss in this post:
- Creating a formal agenda and assigning timeboxes or rough timelines for each item on the agenda.
- Noticing when a discussion has gone past its “expected” time and bringing that fact to the attention of the team.
- Then, offer some options for how to proceed, including changing meeting techniques.
These are regular facilitation skills, nothing fancy. Let me start with the agenda setting.
Facilitative Leaders Set Agendas
I hate meandering, wandering meetings. That's why I wrote a chapter about meetings in Manage It!, with a section called, “Cancel These Meetings.”
Even if you use a “typical” agenda for a biweekly planning session, I strongly recommend you create an agenda for each planning session.
Especially if the team demonstrates what they completed, and then use a retrospective to cement their learning, they will need a new agenda for their planning.
Here's how this works. I'm big on starting and ending in the middle of a week, so the team does not struggle through a weekend or prevent people from leaving early on Friday afternoons for their personal time. In Create Your Successful Agile Project, I recommend the team end an iteration in the middle of a week. (See What's Wrong With Wednesday?) That day needs an agenda.
The Wednesday Agenda
- 9:30- 10 am (or thereabouts) demo the progress the team made.
- 10 am: break and gather any data for the retro, which is next.
- 10:30 am – noon: Retrospective. Since this is the most important meeting the team has, I prefer to spend the most time on it.
- noon to 1 pm: lunch. (I'm agnostic about a group lunch.)
- 1pm – 3pm: Planning, which includes the discussion of the work the product owner would like this iteration, any back-and-forth regarding the content of that work, relative sizing as in “Does each item look like roughly a team day to us?”, and then backlog ranking. If you like a sprint goal, by all means, add it before ranking. See Part 2 for how to reduce necessary planning time.
- 3pm to the “end of the day”: the team starts the next iteration.
The team knows what to expect in the regular time blocks.
Sometimes, the team needs more of an agenda in some time blocks, especially if they have not yet calculated their cycle time or are not yet right-sizing stories.
The Planning Agenda
When I facilitate a team's planning meeting, I start with this agenda, and assume the meeting starts at 3 pm. The expected times are in the parentheses:
- 3 pm: Product owner explains the value she would like to see in this next iteration. Discussion. (15 mins)
- 3:15 pm: Product owner explains the four stories she thinks are up next. Discussion, which includes the right-sizing and anything that might have to occur in advance of these stories. (30 mins)
- 3:45 pm: How does this sprint support the overarching product goal? (Or otherwise create a sprint goal.) (20 mins)
- 4:05 pm: Rank the stories (15 mins)
- 4:20: Summarize iteration's value, the ranking of the stories, and sprint goal. Verify everyone understands and agrees.
- 4:25: Adjourn. (I almost always add a sentence like this: Assume some things might go longer, which is why I said this meeting would go from 3-4:30)
Notice that when we limit the discussion to just the next few stories, we limit the discussion time. If your team doesn't do an interim discussion session, you might need more time here.
Regardless, everyone can see the agenda. That's part of the facilitation.
Notice When the Meeting Goes Sideways
Meetings, just like the product development, can go sideways. That's why a facilitative leader notices when the team goes over the expected time.
The first problem is when the product owner isn't ready to discuss the value for this iteration. That's often a function of the problems in Part 3, where the tactical and the strategic fight for dominance. (I'm not even going to discuss trying to be a product owner for two unrelated products at one time. That's a different problem.)
Can you have a planning meeting with an unprepared product owner? Maybe, but only if the product owner agrees to spend the next few minutes discussing and then deciding on the value. If you don't have a product owner, you're not doing Scrum. You might be using an agile approach, but it's not Scrum. (You don't have to believe me. Read the Scrum Guide.)
If you're not doing Scrum but are using iterations, then the Scrum Master (why call the role that??) will have to supply the information for the team.
There are plenty of other times the meeting can go sideways, but the biggest part of facilitation is noticing that the meeting is no longer on track. No one can offer options if they don't notice.
Offer Other Options
Let's assume that the story discussion is where this meeting goes awry. (The interview question I started with.) The Scrum Master notices. After she says, “We've gone way over our expected time for this discussion,” she can offer some options:
- Ask the team, “What would you like to do, so we can make progress?”
- Offer the team, “Continue this discussion for the next five minutes, stop the discussion, or change modes so we can make progress?”
- Suggest a break, “We've been at this for a long time. How about a 10-minute break, where we get some coffee, shake off the old discussion, and see what we can do next?”
All of these are facilitative possibilities.
No one needs hours of discussion, especially not for the assumption that the Scrum Master is In Charge (and in Control!). That's the topic I'll address in the next post.
The Series:
- How Product Goals Make it Easier to Create Sprint Goals and Reduce Feature Factories, Part 1
- How to Reduce Planning Time to Create Better Goals at All Levels, Part 2
- Integrate Product Owners into Many Teams to Create Good Product Goals, Part 3
- How Scrum Masters Use Facilitative Leadership Especially When Planning, Part 4
- How Interview Questions Reveal the True Organizational Assumptions & Culture, Part 5