One of the things I get asked a lot is which meetings a team should have when. The right answer is that it varies for every team, and it changes over time. Still, it can be handy for new teams to have a starting point. In that spirit, here’s a schedule that I’ve assembled based on a few different smooth-running teams:
|Monday, 9-10a||Iteration planning & kickoff||All team members|
|Tuesday-Friday, 9:30-9:40a||Stand-up meeting||All team members|
|Tuesday, 2-4p||Product stakeholder meeting||Product managers, external stakeholders|
|Wednesday, 10a-12p||Product planning||Product managers|
|Wednesday 4-5:30p||Estimation||All team members|
|Friday, 4-4:30p||Product demo||All team members, external stakeholders|
|Friday 4:30p-5:30p||Process retrospective||All team members|
Isn’t that a lot?
For everybody except the product managers, that’s under 5 hours of formal meetings per week. Once a team is running smoothly, I see many people doing it faster than that.
Still, it’s much better to allocate extra time for these meetings, especially at the beginning. Making an agile transition is hard enough without the stress of blowing out time boxes. Instead of squeezing the schedule down, develop the habit of looking to end meetings early. Only once you consistently end early should you shorten the schedule.
Even as scheduled, this doesn’t end up feeling like a lot. The daily stand-up should be fast-paced and energizing. The meetings that developers must attend are all at the beginning or end of the day, yielding large blocks of uninterrupted coding time. And the Monday morning and Friday afternoon meetings come at times when people are normally spinning up and winding down anyhow.
Notes and caveats
- be doing weekly iterations
- have an on-site product manager (aka XP Customer, aka Scrum Product Owner)
- sit all in one room
- use lightweight artifacts (e.g., index cards, not requirements phone books)
You can divide the meetings up into three groups:
- The iteration planning and daily stand-ups cover what we are doing now.
- The product stakeholder, product planning, and estimation meetings figure out what we may be doing soon.
- The product demo and process retrospective look at what we just did.
The notion is that although the team is mainly focused on what’s going on now, product managers (and sometimes designers) need to work a bit ahead, so that the team can move smoothly into the next iteration.
It’s also important to note that plenty of conversation happens outside of these times. That’s why we all sit together. Rather than trying to make a schedule that formalizes every bit of useful discussion, it’s better to schedule only the minimum number of meetings to get everybody in sync.
Does this leave you with questions or suggestions? Let me know, and I’ll cover them in a future post!