Meetings: The productivity killer for developers

Today’s Fortune 500 organizations are under pressure to rapidly deliver next-generation customer experiences that are high quality and optimized across touchpoints, channels, and devices. Due to intense competition, velocity around software development is critical. While meetings are a necessary evil, an unmanaged approach hurts productivity.

John Jenson

By John Jenson

Meetings are a way of life in corporate culture and developers are not immune. For instance, an agile consultant may recommend that all developers attend ceremonial Scrum meetings each day/week/sprint. These ceremonial meetings usually include Daily Scrum, Sprint Planning, Grooming, Sprint Review/Demo, and Sprint Retro. Any time all developers attend a meeting, the cost is high. Make sure the cost is justified by the value added from each person attending.

In our recent work with a large media client, we used a Scrum process, the most widely adopted agile framework. Let’s look at the cost of a typical sprint’s ceremonial Scrum meetings. The cost in terms of developer time is based on an eight developer team with two week sprints.

*This includes time for developers to get back to their desks, wrap up conversations, and reload their mental headspaces after each meeting.

Notice that the cost of the ceremonial meetings in this scenario is more than just the 44 hours that are spent in the meetings. The stops and stars introduce mental context switches for all involved. If we apply a 15 min tax for each developer for each meeting, we lose another 30 hours or 74 hours per sprint. While 44 hours may be considered time well spent, when we add the additional 30 hours, we can see that there is room for improvement.

In my experience, loss related to context switching is less impactful for remote attendees who only simply click a button to join. But, I have observed the above scenario to be quite accurate in corporate settings where large teams gather physically.

What does a framework like Scrum have in common with the actual Manifesto for Agile Software Development? Well, nothing really. Agile isn’t about a specific meeting cadence. It is about writing software that incrementally provides real business value. You don’t have to hold a specific number of meetings to be agile. Frameworks like Scrum and Kanban are just perspectives, not commandments.

Adopt a High Velocity Solution

Choose to keep meetings that provide high value, combine meetings, and remove those that can’t be justified (or reduce the audience so the cost goes down). Let’s look at how we can make typical Scrum meetings less costly.

Daily Scrum Meetings

I often see daily Scrum meetings last 30 mins when they should take 15. Here is a recipe for a successful Scrum meeting.

  1. Each participant should update their tickets before the meeting starts.
  2. Display the Scrum board on a screen that all can see.
  3. Filter tickets by name, and one-by-one, address each person individually.
  4. Ask these questions.
    1. Are your tickets updated with the latest details and status?
    2. Is there anything blocking you?
    3. Are you spending time on something that isn’t on the board?

In a well-running Scrum process, no news is good news. If things are running smoothly, and tickets are moving across the board as expected, then this response is perfectly acceptable. “My tickets are up-to-date and I have no blockers”.

The Scrum master must notice one primary trend: Are tickets moving across the board as expected? If a ticket on the board is expected to take one day, but it has been in progress for two or more days, ask why. Make sure that blockers are removed, and that no tickets are taking significant time without good reason. The best Scrum masters take notes about what people are working on and what is blocking them. Good Scrum masters see from their notes that a blocker remains for multiple days and calls for sidebars to resolve problems. Too often Scrum masters don’t notice trends and avoid notes. If it takes more than 15 minutes to get through the Scrum, then it’s likely that too many people are sharing more detail than they should. If this is the case, the Scrum master should ask for concise responses and clarify what this entails.

Is Eliminating Daily Scrum Possible?

Since the Scrum meeting is the most costly, could it be eliminated? One coworker ran his Scrum over team chat, which could be effective for some teams, but not all.

How do you address the need to discuss blockers? In place of the Scrum meeting, the Scrum master can schedule an optional meeting for sidebar conversations that come out of the Scrum chat. Participants would only be required to attend when there is something to discuss.

Meetings over chat don’t change the responsibility of the Scrum master or the meeting participants in terms of reporting, but they free the team up. You can also experiment with other cadences, e.g., holding meetings twice a week in person, and three times a week over team chat. Favoring communication channels that are real-time but asynchronous, such as chat rooms, allow people to remain focused when questions arrive, then respond later when they have emerged from intense thought.

Sprint Grooming/Planning

Grooming and planning should ensure a healthy backlog of tickets. The tickets must outline clear expectations, be immediately playable, and have an estimate. Is there a reason for two separate meetings? I don’t think so. Does every developer on the project need to hash out the details? I say no. If you want to move at a higher velocity, then send only one senior-level developer to grooming and planning meetings, not the whole group. Your team can only move at high velocity if the stories are well written, and assumptions in them are correct.

Teams typically validate the assumptions and ask questions about acceptance criteria during grooming and planning. It takes a lot of effort to validate all of the assumptions, and acceptance criteria. If you engage the whole group, you’ll never have enough time. As a result, you will rush and end up with stories that are poorly groomed, and that will cause delays.

Writing tickets is often considered the work of the analyst obtaining input from the product owner, but he/she needs someone from the development team to help get it right. The developer needs to proofread the analyst’s stories and make sure the needed acceptance criteria are present and there is no ambiguity. The analyst needs facetime with a developer to get it right, so give it to him/her. Hold a small recurring meeting with the analyst, product owner, and one developer throughout the sprint. For projects that I have run, grooming stories for up to an hour per day has worked well during periods of intense planning, and as quickly as 20 minutes per day when things are running more smoothly.

While the senior developer is present for the grooming meeting, have him/her provide estimates too. Coming back later as a large group is extremely costly, and for what? Remember, it is only an estimate after all. A lot of teams like to get fancy with planning poker cards. And, while it is nice to estimate as a group, I’m not confident that it is much more accurate than one senior person’s estimate, but I can confidently say it is more costly.

By combining grooming and planning into one meeting, reducing developer attendance to one developer, and holding it regularly, you use 10 well-spent developer hours per week on grooming, instead of 30 less effective developer hours. Even though you spend fewer developer hours per sprint on grooming, you will actually have more time to get the stories right because you won’t be rushed.

Sprint Retro

Retros are useful when a team is starting to working together, but they quickly become unnecessary once the kinks are worked out. Stop holding them once they become unnecessary. Let the team know that retros can be held at any time per their request going forward.

Time Savings

Making these changes allows you to save about 52 developer hours per sprint. For a team of eight, this amounts to about eight percent more developer hours for other productive tasks. Take a look at the revised meeting schedule.

In Summary

Recurring meetings can be costly, especially if they are held every day and all team members must attend. The main takeaway should be to pay attention to how time is used in meetings. Ask yourself if the goals of the meeting can be accomplished in a different way. Or, could the meeting be eliminated altogether? There may be a more effective approach. If you feel like Scrum is getting in the way of productivity, you may be happier with another agile framework such as Kanban. No matter what you choose, optimize it for your team. Remember that neither Scrum or Kanban make you agile. They are both just frameworks that work within agile.

Today’s Fortune 500 organizations are under pressure to rapidly deliver next-generation customer experiences that are high quality and optimized across touchpoints, channels, and devices. Due to intense competition, velocity around software development is critical. While meetings are a necessary evil, an unmanaged approach hurts productivity.

John Jenson

By John Jenson

Meetings are a way of life in corporate culture and developers are not immune. For instance, an agile consultant may recommend that all developers attend ceremonial Scrum meetings each day/week/sprint. These ceremonial meetings usually include Daily Scrum, Sprint Planning, Grooming, Sprint Review/Demo, and Sprint Retro. Any time all developers attend a meeting, the cost is high. Make sure the cost is justified by the value added from each person attending.

In our recent work with a large media client, we used a Scrum process, the most widely adopted agile framework. Let’s look at the cost of a typical sprint’s ceremonial Scrum meetings. The cost in terms of developer time is based on an eight developer team with two week sprints.

*This includes time for developers to get back to their desks, wrap up conversations, and reload their mental headspaces after each meeting.

Notice that the cost of the ceremonial meetings in this scenario is more than just the 44 hours that are spent in the meetings. The stops and stars introduce mental context switches for all involved. If we apply a 15 min tax for each developer for each meeting, we lose another 30 hours or 74 hours per sprint. While 44 hours may be considered time well spent, when we add the additional 30 hours, we can see that there is room for improvement.

In my experience, loss related to context switching is less impactful for remote attendees who only simply click a button to join. But, I have observed the above scenario to be quite accurate in corporate settings where large teams gather physically.

What does a framework like Scrum have in common with the actual Manifesto for Agile Software Development? Well, nothing really. Agile isn’t about a specific meeting cadence. It is about writing software that incrementally provides real business value. You don’t have to hold a specific number of meetings to be agile. Frameworks like Scrum and Kanban are just perspectives, not commandments.

Adopt a High Velocity Solution

Choose to keep meetings that provide high value, combine meetings, and remove those that can’t be justified (or reduce the audience so the cost goes down). Let’s look at how we can make typical Scrum meetings less costly.

Daily Scrum Meetings

I often see daily Scrum meetings last 30 mins when they should take 15. Here is a recipe for a successful Scrum meeting.

  1. Each participant should update their tickets before the meeting starts.
  2. Display the Scrum board on a screen that all can see.
  3. Filter tickets by name, and one-by-one, address each person individually.
  4. Ask these questions.
    1. Are your tickets updated with the latest details and status?
    2. Is there anything blocking you?
    3. Are you spending time on something that isn’t on the board?

In a well-running Scrum process, no news is good news. If things are running smoothly, and tickets are moving across the board as expected, then this response is perfectly acceptable. “My tickets are up-to-date and I have no blockers”.

The Scrum master must notice one primary trend: Are tickets moving across the board as expected? If a ticket on the board is expected to take one day, but it has been in progress for two or more days, ask why. Make sure that blockers are removed, and that no tickets are taking significant time without good reason. The best Scrum masters take notes about what people are working on and what is blocking them. Good Scrum masters see from their notes that a blocker remains for multiple days and calls for sidebars to resolve problems. Too often Scrum masters don’t notice trends and avoid notes. If it takes more than 15 minutes to get through the Scrum, then it’s likely that too many people are sharing more detail than they should. If this is the case, the Scrum master should ask for concise responses and clarify what this entails.

Is Eliminating Daily Scrum Possible?

Since the Scrum meeting is the most costly, could it be eliminated? One coworker ran his Scrum over team chat, which could be effective for some teams, but not all.

How do you address the need to discuss blockers? In place of the Scrum meeting, the Scrum master can schedule an optional meeting for sidebar conversations that come out of the Scrum chat. Participants would only be required to attend when there is something to discuss.

Meetings over chat don’t change the responsibility of the Scrum master or the meeting participants in terms of reporting, but they free the team up. You can also experiment with other cadences, e.g., holding meetings twice a week in person, and three times a week over team chat. Favoring communication channels that are real-time but asynchronous, such as chat rooms, allow people to remain focused when questions arrive, then respond later when they have emerged from intense thought.

Sprint Grooming/Planning

Grooming and planning should ensure a healthy backlog of tickets. The tickets must outline clear expectations, be immediately playable, and have an estimate. Is there a reason for two separate meetings? I don’t think so. Does every developer on the project need to hash out the details? I say no. If you want to move at a higher velocity, then send only one senior-level developer to grooming and planning meetings, not the whole group. Your team can only move at high velocity if the stories are well written, and assumptions in them are correct.

Teams typically validate the assumptions and ask questions about acceptance criteria during grooming and planning. It takes a lot of effort to validate all of the assumptions, and acceptance criteria. If you engage the whole group, you’ll never have enough time. As a result, you will rush and end up with stories that are poorly groomed, and that will cause delays.

Writing tickets is often considered the work of the analyst obtaining input from the product owner, but he/she needs someone from the development team to help get it right. The developer needs to proofread the analyst’s stories and make sure the needed acceptance criteria are present and there is no ambiguity. The analyst needs facetime with a developer to get it right, so give it to him/her. Hold a small recurring meeting with the analyst, product owner, and one developer throughout the sprint. For projects that I have run, grooming stories for up to an hour per day has worked well during periods of intense planning, and as quickly as 20 minutes per day when things are running more smoothly.

While the senior developer is present for the grooming meeting, have him/her provide estimates too. Coming back later as a large group is extremely costly, and for what? Remember, it is only an estimate after all. A lot of teams like to get fancy with planning poker cards. And, while it is nice to estimate as a group, I’m not confident that it is much more accurate than one senior person’s estimate, but I can confidently say it is more costly.

By combining grooming and planning into one meeting, reducing developer attendance to one developer, and holding it regularly, you use 10 well-spent developer hours per week on grooming, instead of 30 less effective developer hours. Even though you spend fewer developer hours per sprint on grooming, you will actually have more time to get the stories right because you won’t be rushed.

Sprint Retro

Retros are useful when a team is starting to working together, but they quickly become unnecessary once the kinks are worked out. Stop holding them once they become unnecessary. Let the team know that retros can be held at any time per their request going forward.

Time Savings

Making these changes allows you to save about 52 developer hours per sprint. For a team of eight, this amounts to about eight percent more developer hours for other productive tasks. Take a look at the revised meeting schedule.


In Summary

Recurring meetings can be costly, especially if they are held every day and all team members must attend. The main takeaway should be to pay attention to how time is used in meetings. Ask yourself if the goals of the meeting can be accomplished in a different way. Or, could the meeting be eliminated altogether? There may be a more effective approach. If you feel like Scrum is getting in the way of productivity, you may be happier with another agile framework such as Kanban. No matter what you choose, optimize it for your team. Remember that neither Scrum or Kanban make you agile. They are both just frameworks that work within agile.

Interested in partnering with us?

Send a message and we will work with you to understand your needs.

Related Insights from Our Experts
Related Consulting Solutions

Journey Mapping

Visualize your customer’s pain points and gaps, and create the future state customer journey. We put our tried and true journey mapping methodology to work to align your organization around your customer and use our Cora Journey360 platform to help create, store and share these assets.

Customer & User Research

Ground your CX initiatives on real insights uncovered via contextual inquiry.

2019-03-08T11:16:31-05:00