Does your Scrum Team hold too many meetings?

Does your Scrum Team hold too many meetings? Here’s how to reduce them and reclaim some valuable time.

I’ve heard many grumbles and complaints from Scrum Team members about having too many meetings distracting them from Sprint work. For Scrum to be successful, team members need to communicate regularly between themselves and with others around the organisation, so meetings come with the territory. 

We shouldn't forget that meetings enable collaboration, knowledge sharing, involvement in decision making, and improvement. Most of us wouldn't be happy in a job where we couldn't do those things. However, it’s always possible to have too many of them, especially when there’s Sprint work to be getting on with. 

Are there too many Scrum events?

As Scrum Master, I’ve often been asked by stressed out teams whether they can skip a Scrum event, shorten one, or push it into the next Sprint. The Scrum events provide boundaries which make it safe for Scrum Teams to self-manage; omitting any of them reduces transparency and the opportunities to inspect and adapt. As a result, team commitments could be at risk of failure. Delaying the events such as the Sprint Review and Sprint Retrospective could lead to teams beginning a new Sprint without learning vital lessons from the previous one. 

Daily Scrum 

Let's consider the impact of excluding the Daily Scrum – with a timebox of just 15 mins it’s surely doable even on the busiest of days. Without taking this opportunity to check progress towards the Sprint Goal and make any adaptations necessary to achieve it, the team risks wasting a whole day focusing on the wrong thing or proceeding in the wrong direction. There’s also the risk of impediments and blockers remaining unresolved, leaving the Sprint Goal hanging in the balance.  

Product Backlog Refinement 

I’ve witnessed refinement sessions being readily discarded on occasion. The Product Backlog might look acceptable at the time, but reducing the time spent refining it usually has a knock-on effect on future sprints. The team may find themselves without enough development-ready backlog items when the next Sprint Planning meeting comes around. As a result, planning takes a lot longer than it should, owing to a segue into some last-minute refinement that, when rushed, could lead to misunderstood requirements, delays and/or rework. 

Sprint Planning 

The Sprint Planning event is usually accepted by teams as a necessity. Without it, they don’t have an agreement on what they are committing to or which backlog items they should pull into Sprint. They wouldn’t be able to provide a forecast to inform and set the expectations of their stakeholders and without that transparency, they are likely to be interrupted to answer questions. 

Sprint Review

As the Sprint nears its end, meetings are more likely to be deemed an inconvenience especially if there is a rush to complete unfinished Sprint work. The first event to occur during this busy period is usually the Sprint Review, which the team might try to avoid because they are eager to finish any work that is still in progress. Some teams don't see the need for all members to attend; this is especially true when the Sprint Review has taken the form of a demo. Demos can usually be covered by one person, but a Sprint Review (when executed correctly) requires the whole Scrum Team and stakeholders to inspect the Product Increment, the progress made towards the Product Goal, and any changes in the market before collaborating on the plan for future iterations. Without a proper Sprint Review, the team could be missing out on valuable feedback needed to ensure they’re delivering the highest value features. 

Sprint Retrospective

Last but by no means least is the Sprint Retrospective. A request to forego this event could be a red flag signalling a lack of commitment to continuous improvement. This is the time for the team to air concerns, address issues and agree on the adjustments needed to improve team practices, processes and interactions. Without it, the team could leave issues unresolved, reducing their productivity in future sprints. They also limit their ability to grow and mature as a team, and reach higher levels of performance.

Optimise your Scrum Events to reduce the need for other meetings 

It’s clear the Scrum events all serve a purpose and alone don't amount to an excessive number of meetings. When teams use their Scrum events efficiently, they can reduce their overall meeting count. It is therefore useful to evaluate, look for opportunities to improve them and avoid generating additional and avoidable meetings. 

Increase transparency in the Daily Scrum 

Let's firstly look at the Daily Scrum, anyone working on Sprint Backlog items can participate in this event (as a developer) to share updates and collaboratively plan the day’s work. The team can invite anyone from outside the team who could provide useful insights. Special guests may include members of another team if there is a cross-over or dependency, or anyone involved in resolving an external impediment or blocker. Without their attendance it's likely a separate catch-up will be needed to establish progress and the impact on the Sprint Goal. 

Let's be clear: the Daily Scrum is not intended to be a progress update for people outside the development team; its purpose is to allow developers to assess their progress towards the Sprint Goal and make a plan for the day. However, in the interest of transparency and avoiding further meetings, it could make sense for a stakeholder to attend – strictly as an observer, I must stress – to gain some transparency and avoid needing to disturb the team separately with questions. Arguably, the Product Owner or Scrum Master could keep them updated but the team may decide it makes sense for them to attend. 

Increase the knowledge available in Product Backlog Refinement and Sprint Planning 

Product Backlog Refinement and Sprint Planning events can benefit from the attendance of external experts who can answer any of the team’s questions there and then, to avoid extra meetings. Similarly, where there’s a dependency on another team, it might make sense to invite a representative along to Sprint Planning to help with the coordination of effort. 

Encourage Stakeholder involvement

Sprint Reviews that take place in the absence of key stakeholders can necessitate further meetings to chase after missing feedback. This then has the potential to spin off into even more meetings to relay that feedback and make plans to incorporate it. Unfortunately, simply inviting all the right stakeholders to the review doesn't guarantee their attendance, despite best endeavours to accommodate their preferred time and location. 

Scrum Masters can help educate Stakeholders on the importance of the event and encourage them to put it higher on their list of priorities. Focusing on making the review as collaborative and productive as possible will also help increase attendance.

Encourage openness in Sprint Retrospective

When there is a lack of trust within a team, members may not seize the opportunity to raise issues and concerns during the Sprint Retrospective; they may prefer to keep them under wraps and avoid conflict. This allows artificial harmony to reign until the unfortunate occasion when a concern turns into an issue in need of prompt attention. Then – you guessed it – another meeting is needed to tackle it. 

Deciding to put heads together and tackle an issue is the best course of action as it shouldn’t be left unattended to cause further damage until the next retrospective. Crisis meetings like these can be avoided by focusing on building trust and encouraging openness in retrospectives so that concerns are raised and addressed before they turn into serious problems. 

Is the quantity of meetings the issue?

Sometimes the problem with meetings isn’t the quantity or the content. Sometimes, it’s the timing or lack of advance notice. Maybe there are too many or too few people involved in them.  

Avoid context switching 

I’ve often been told how frustrating it is to get absorbed in complex work only to have to stop for a meeting. It might take a while to get back to the same stage in the thought process, so context switching has the potential to extend the time spent on a particular piece of work.

There are ways of reducing the need to switch context, for example, scheduling events first thing in the morning, either side of lunch, or last thing in the afternoon (although people might not be their most energetic selves by then). Considerate scheduling can give the team longer stretches of developing time. That being said, it can be hard to please everyone: some people prefer to have all their meetings back to back to get them out of the way, others would rather stagger them, some prefer morning meetings over afternoons, etc. 

Increase involvement of quieter team members

Meetings can be a chore when there’s little opportunity to actively participate, and I’ve often attended meetings that have been dominated by one or two people. Those who don’t get a chance to contribute may resent having to attend, and given the option would probably rather skip and get a summary afterwards. I’ve observed quieter team members emerge from their shells during meetings when the more dominant team members are absent, only to retreat again upon their return. Scrum Masters can help team members recognise this imbalance and facilitate a more even distribution of airtime between team members to keep everyone engaged. 

Choose participants carefully

It’s important for Scrum teams to be open and transparent and share knowledge, but that doesn’t necessarily mean the whole team should be present for every discussion. For example, early discussions about potential new features and concepts could take place between just a few team members, perhaps in a 3 amigos session; then, once the idea advances towards the Product Backlog, the rest of the team can get involved. This could save the whole team from wasting time discussing work which doesn’t come to fruition.

Make sure key people attend

As I mentioned in relation to Sprint Reviews, meetings can be less productive when key people don’t attend, creating further meetings which shouldn’t have been necessary. Poor attendance of Scrum events needs to be rectified quickly, as unproductive meetings can lead to unproductive teams. The solution may be as simple as rescheduling the meeting to a more convenient time, but it could require a Scrum Master to educate the team and stakeholders on the importance of the event, and the risks introduced when it doesn’t achieve its purpose. 

Make the meeting objective clear so that participants come prepared

Meetings attended by all the right people can still be unproductive if the attendees are poorly prepared for what they are going to discuss. When the objective of a meeting isn’t clear, there’s no opportunity to gather any necessary information beforehand. The meeting may achieve little more than an agreement to schedule another meeting, which wouldn’t have been needed had everyone been prepared the first time around. This is how “meetings about meetings” happen. 

Conclusion

Hopefully, this answers the question of whether your Scrum Team has too many meetings. The answer requires an assessment of the Scrum events to determine whether they achieve their objectives or if additional meetings are needed to gather missing requirements, feedback, and technical knowledge, or to understand the status of other work on which the team depends. Fine-tuning Scrum events and extending invites to relevant people can reduce wasteful meetings and free team members up to focus on Sprint work. 

There will always be meetings beyond the Scrum events – but this can be a positive sign that an organisation has a culture of transparency and values its employees for their opinions and expertise.

‍