Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
A Responsible Recipe for the Fewest Possible Meetings

Meetings are crucial to healthy team communication. But they’re also opportunities for waste, occasionally dull, and always expensive. Every team is different, but continuing the theme of “Convention over configuration for process”, I’ve found the following structure keeps meetings to ~7.5% of your week. This minimizes waste, maximizes making-time, and makes for a nice scheduling default for projects.

1. Daily Standup

5x weekly, 10 minutes each

Standup is a short, team-wide orientation meeting. Each morning, the team meets for a the Team Stand-Up meeting. As it’s name implies, everyone should be standing up—even if they’re remote and parked behind a screen. Meetings tend to run short when everyone’s on their feet, and there isn’t much to cover anyway, just three canonical questions:

  • What did you do yesterday?
  • What are you doing today?
  • Are you blocked on anything?

Since the team is pairing, most of the time the second person will say “pass” since their pair already mentioned the stories they worked on, the issues they had, and what they’re doing next: sticking together or seeking a new pairing partner.

2. Iteration Planning Meeting (“IPM”)

1x weekly, 60 minutes each

The IPM is a weekly tactical planning meeting. It’s aim is to ensure that the backlog is in good shape, and that all the team members have a shared understanding of what the stories mean. The product manager leads the meeting by reviewing the backlog. Each story should be reviewed; questions can be answered, clarifications can be issued, and developers can estimate the stories. Ideally, the meeting is on Monday or Tuesday and the team will get through the current iteration’s undone stories and a healthy chunk of next iteration’s stories. On some teams, it helps to take an hour before the IPM to groom the backlog, prioritize, and flesh out poorly-worded stories, and review mockups for hidden features in a pre-IPM meeting with a small group (usually the Product Owner and a single developer).

3. Friday Afternoon Meeting

1x weekly, 60 minutes each

A useful pattern on recent projects has been to block out an hour Friday afternoon and rotate between three meetings: the Team Retro, the Tech Retro, and the Release Planning. It’s nice to have a regular time, and every-three-weeks is about the right frequency for each of these.

Week 1: Team Retro

The Team Retro is a chance for the day-to-day members of the team to reflect on how things are going, celebrate successes, voice frustrations, and suggest Action Items. While there are plenty of variations, the classic Retro format is to throw three columns on a whiteboard:

  • “Smileys”, or things that are going well, represented by the expected emoticon :-)
  • “Frownies”, or things that are going poorly, represented by :-(
  • “Mehs”, or things that don’t fit cleanly in either category, but bear mentioning :-

After ~25m of going around the room and throwing out Smileys, Frownies, and Meh’s, the team might spend a few minutes identifying items which have a common theme, and then spend the rest of the time suggesting action items, either for each item (starting with the Frownies) or, if time is short, on a theme-by-theme basis. The action items are recorded and assigned to individuals, and their progress is followed (often at the start of the next retro). For more about Team Retros, see 7 Best Practices for Facilitating Agile Retrospectives.

Week 2: Tech Retro

A Tech Retro is for and by developers. While pair-programming is essentially continuous code review, it can still be useful to take some time to step back and look at the codebase. Tech Retros often take the traditional “Smilely / Frownie / Meh” format, but focus exclusively on the codebase. This is a great time to talk about modeling decisions and suggest refactors. Often the action items resulting from tech retros are a long list of chores. Try to keep each one to a manageable size, and make sure at least a few of them make it into the backlog for the next iteration.

Week 3: Release Planning

“Release Planning” means different things to different Agilists, but in this context it’s a loose title for a long-range planning meeting. While the IPM is a short-term tactical meeting, it’s important to occasionally step back and look at the big picture. What are the product’s medium- and long-term goals? Are we on track? What should our next milestone be? The Release Planning should be attended by the whole team, and by the stakeholders like clients and CEOs who may not be part of the day-to-day workings of the team. It’s a chance to review epic story tracks, dates and deadlines, and to make sure that everyone has a shared vision of where the team is going—and that it’s a place worth going to.

Why Meetings Matter

Communication is crucial, but so striking a balance between waste and on keeping everyone on the same page. I’ve found that teams which hew to this schedule tend to have a healthy rhythm. While circumstances occasionally require additional meetings, especially on the part of the Product Owner or the outward-facing members of the team, this structure is sufficient to maintain healthy intra-team communication without taking developers away from code any more than necessary.

Do you have another default meeting structure that you like? Let’s hear about it in the comments!

  1. Don Mullen says:

    Great article, Jonathan. Thanks for sharing.

    I would add a Risk Assessment meeting to the Friday mix, with the goal of putting together a prioritized list of risks, and how the team means to address them. Team retros are generally looking back at how things went, while Risk Assessments are forward looking and proactive.

    I’ve also found that changing the retrospective format keeps things from getting stale. Agile Retrospectives, by Derby/Larsen ( has many excellent retrospective exercises to mix things up a bit.

  2. Leena says:

    Hi Jonathan,

    Good article and thanks for sharing. At my current company, Multunus, we were following fixed time weekly meetings and it has been working. Recent past, we’ve started realising that lack of having tech oriented meetings [similar to Tech Retro as mentioned by you in the above post]. Is it possible for you to share your experience with the above meeting structure or any challenges you faced with the above approach for fixed time meetings?


  3. Leena says:

    Excellent article, very useful. Thanks for sharing.

    Right now we have a single meeting for everything together and we realised that it takes too much time for the meeting and too many different decisions/action items are taken in one meeting. So we were thinking of splitting into multiple smaller meetings which are focussed and structured, somewhat as suggested by you above. We’ve just started on it now.

    But I’ve some questions though:

    – Would like to know whether this is something you are still following? I am sure there would have been improvements, but are you still following the same pattern?
    – Would you be able to share some challenges or “aha” moments you had?

    Thanks once again

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *

Share This