How to reduce planning meeting time involving several teams?

Question

I'm working on a project having planning meetings at the start of every sprint. Three teams are involved on every planning meeting, reviewing pending/todo issues team by team (every issue is estimated).

Some members have requested to conduct separate meetings, one per team, to not lose much time.

Initially, it was proposed to make meetings together because sometimes there are dependencies between teams.

What would you advise me to conduct these meetings?

Thanks!

Answer 1

Scrum of Scrum meetings should handle dependencies between teams

It is not recommended to have planning meetings with multiple teams together. With such a large number of people, team members won't be able to pay attention, as you are finding out. For coordinating cross-team dependencies, you can have separate scrum of scrum meetings. Please see more on this from Mike Cohn:

• Scrum of scrum meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration.
• Each team would designate one person to attend the scrum of scrums meeting.

Answer 2

You may need to amend the scope of your meetings so that they are more efficient. One approach would be to have a series of smaller meetings:

• The first meeting in the series (and of a sprint) would be inter-team with key team leaders who have the knowledge and authority to speak for their teams. At these meetings you could talk about their issues, review dependencies, etc which impact the project as a whole.
• The remaining meetings in the series would be intra-team planning meetings led by the key team leaders, and would be used to decide on the details of how to implement the decisions made at the inter-team meeting. These meetings could be run concurrently by your three teams.

Taking this approach has the advantage of reducing meeting time for lower-level team members (the doers), helps keep high-level and low-level discussions at the level they should be at, clearly delegates authority and responsibility to the key team leaders, and keeps the number of voices in a room to a level where they can all be heard.

Answer 3

I was in a similar situation a couple of years ago. We had a large meeting, because we thought that it was the best way to solve dependencies. We observed that most of the participants weren't listening, because the discussion was irrelevant to them.

As a solution, we kept the meetings in the same time but at different places, near to each other. So when a dependency problem came up, we sent a message to the other team saying that we would go over in 5 minutes and discuss it. They had time to finish what they were doing, and be ready for the next discussion. It really worked. I'm not with those teams anymore, but as far as I know they still do the meetings in this fashion.

Answer 4

If the goal is to reduce meeting planning time, then hold a single meeting and timebox it. A single one hour meeting fits the goal better than three one hour meetings.

However the question text hints that there may be more constraints on the goal. I think the answers provided by others are correct, but if I were in your shoes, I would hold three meetings and include three mandatory agenda items for each meeting:

1. Are there any (new) dependencies between this sub-project and either of the others?
2. Close any reconciliation identified to other teams
3. Reconcile all dependencies identified by other project teams. (inbound reconciliation)

I'd also schedule additional ad hoc meetings to reconcile any dependency that isn't reconciled immediately. (that is to say if Team X proposes to team Y that there X.1.3.4 is a dependency on Y.2.5, and Team Y doesn't resolve that dependency satisfactorily the first time it is considered then schedule an ad hoc meeting with all the players needed to resolve the problem.)

Answer 5

As with most questions, the answer is "it depends". So a couple of questions -

• Are the teams/dependencies heavily inter-related?
• Are there central points of contact for each team that could attend and then relay information/decisions?
• And most important - what's the history of the projects/teams? do you foresee issues in decoupling the team meetings?

You need to look at each of the above questions in relation to YOUR situation and decide from there.

Have there been dependency/coordination issues in the past? Then they need to attend. And they need to understand why.

Is information reliably relayed by one or two people? then just have those people attend and leave the rest of the team to keep working.

And one more option would be tell the team you're changing, but ONLY on a trail basis. If issues appear then you're going back to the full team meetings.

Answer 6

I am currently looking after three projects; A, B, and C, which solutions are being developed by three different teams as follows:

• Project A - Team Green
• Project B - Team Blue
• Project C - Team Yellow

Our sprints are 3/4 weeks long commencing at the same time for all projects.

Projects A and B have several dependencies of Project C. Likewise, Project C has dependencies of both Projects A and B.

At the beginning of the sprint I set up three sprint planning sessions, one per project/team. These sessions are shorter in time, never longer than a 1h, and are focused on what needs to be delivered in order to achieve the goals of the increment.

During the session, we identify and raise any dependencies that we have with the other projects which I collate in a Sprint RAID Log. In this document I highlight the dependency and team working in that area.

The same meeting process occurs for every other project/team.

At the end of that day, I have good visibility of the correlation and dependencies among these projects, so the following day I set up a 30 min RAID review session with the parties involved to run through these dependencies and agree a mitigation plan (some actions may be taken during the current sprint or may be considered for later phases of the project).

The key aspect here is that by the time we have the RAID review, the following day after individual sprint planning sessions, each team (solution developers, testers, Product Owners, and myself as PM) knows what they are working towards so we can discuss how to they are going to work to resolve these dependencies in a more efficient manner.

From my selfish point of view, running three separate sessions with the teams the same day is quite tiring however, from a practical perspective, shorter individual sessions (instead of 2-3 hour meeting) keeps the team focused preventing them from context switching which, at some point, exhausts them impacting their concentration and attention to the conversation. In the end this increases the risk of misunderstandings and the need for further meetings throughout the sprint (wasting more time).