Time Spent in Scrum Meetings (2024)

Jasper Bogers

Published in

Serious Scrum

Product Backlog refinement is not one meeting

The Product Backlog refinement isn’t actually an event in the strict sense of the word. It’s a range of activities you do throughout the Sprint with one purpose: to understand the work ahead of you.

The Product Backlog refinement does not have to be 1 meeting of 4 hours with the entire team every week.

An event storming or example mapping session can count as Product Backlog refinement just as much as an informal chat with the Product Owner during the morning coffee about some idea they have for a new feature.

Spend the time you need up to this maximum

The times mentioned above are what the Scrum Guide considers the maximum amount of time.

Don’t go beyond this.

In fact, there can be reasons to spend less time:

Your team is small. Alignment and agreement take little time.
Your work is more a matter of volume than of complexity and takes little effort to fully comprehend.
Your team is familiar with the kind of work they take on. Subject matter expertise is a common good.
Your team is familiar with each other and can quickly discuss problems and align on solutions.
Your team has proven to be capable of filling in the details during implementation. Have some faith in your ability to figure things out as you proceed. Also a thing to note: the Product Backlog refinement is not the moment for a technical deep dive. If you know enough about the What & Why, move on; the Sprint Planning and the Sprint itself are when you get into the How.
Your team communicates continuously. You don’t need to have an explicit meeting to communicate.
Your team comes to meetings well prepared. I can’t stress this enough: Nothing kills motivation more than coming to meetings unprepared or surprising each other with items that could have been addressed or announced earlier.
If your meeting has an agenda and you’ve worked through it: stop talking. There’s no need to sit out a time slot just because you allocated it.

Working part time

If you work part time, the aforementioned 9 hours will mean a relatively higher percentage of your time.

Daily Scrum, Sprint Planning, Sprint Review, and Sprint Retrospective are events that take the same amount of time whether you work 24, 32, 36 or 40 hours a week.

As for Product Backlog refinement: it usually consumes no more than 10% of the capacity of the Development Team. And as mentioned earlier: it doesn’t have to be 1 big team meeting.

Avoid interruptions

Diving into a problem, coming up with how to solve it and then implementing it are activities that generally benefit from uninterrupted attention. This suggests you should plan meetings in such a way that this is made possible.

Another form of interruption is the ad hoc meeting. Taking a break to let your mind work is a great idea. It is not the same as having to drop work at a moment’s notice.

If your team has to deal with such interruptions, see if you can appoint someone on a daily or weekly basis to be interrupted first so other team members can concentrate.

Time of day

Figure out which time of day works best for everyone to have a meeting. The exact time of day is different from one person to the next. Keep track of when you’re most productive implementing solutions, and plan meetings around that.

Structure is important, but you may want to change this from time to time if preferences vary greatly between team members.

Before accepting any other kind of meeting that isn’t a Scrum Event, especially recurring ones for your entire team, ask yourself if there isn’t a Scrum Event for it already.

Management wants to know what you’re doing?

Remember the Scrum Values transparency, openness and inspection. You should want to share whatever it is you’re doing. Have information radiators and be willing to explain it to whoever shows an interest.

You don’t need a team meeting for this.

That said:

Managers can attend the Sprint Review.
Managers can attend (but not interrupt) the Daily Scrum.
Managers can read up on your action points regarding process following from your Sprint Retrospectives.
Managers can read up on performance metrics that your team has made available.

A need to know is not the same as a trust issue. Trust and fear issues between team and management can and will hamper progress. They should be addressed and solved by the Scrum Team.

The Scrum Master can help identify such issues.

Your team should not fear management misinterpreting or abusing what you make transparent.

Vice versa, it should not be a strain on the team to produce insights that satisfy management’s curiosity. It should be information you can easily produce and may find useful yourselves.

Stakeholders want to know about velocity, story points, and T-shirt sizes for features?

As a developer, don’t be tempted to commit hours, story points or other measures of velocity or cost that you’ve been using inside your Scrum Team. Don’t let yourself be lured into roadmap and forecast meetings with stakeholders.

These are questions about the Product Backlog. That’s where the Product Owner comes in. The Product Owner can ask developers for advice, of course. And with the Product Owner being regularly involved with the team’s progress through the Scrum Events, that shouldn’t involve that much additional time.

One reason many software developers complain about time spent in meetings, is that they’d rather spend that time solving problems by writing code. I recognize that feeling all too well.

Yet I also think it is a misconception that the core competence of a software developer is to write code. The core competence is to provide solutions through software. Understanding problems precedes providing solutions. That requires time to read, listen and discuss the problems.

In fact, the Scrum Guide talks about developers in the broad sense of the word. Anyone in a Scrum team who is not the Product Owner is by definition a Developer.

UX expert? Developer.

Business analyst? Developer.

Test engineer? Developer.

Operations engineer? Developer.

You catch my drift. There’s a reason for this.

These people are all involved in the Scrum Events, to align and understand what’s required to deliver valuable increments of work. It is this alignment, this shared understanding of what is needed and what has been done, that is so crucial in software delivery.

Consider the following.

It is better to write one line of code that helps deliver value than to have 1000 lines of code that don’t.

The other extreme is getting stuck in analysis paralysis and Big Design Up Front, two things that made people ditch Waterfall in favour of Scrum in the first place. Sometimes you won’t know the value of an idea until you’ve implemented it and measured it in production, so know when to stop talking, and start experimenting and learning!

All things considered, I think spending a minimum of 75% of your time on solving problems together, given enough time to understand the problems that need solving, sounds like a pretty good deal.

This article was originally published on the JDriven blog at https://blog.jdriven.com/2020/03/how-much-time-in-scrum-events/ . It’s been revised here based on feedback received from the Scrum community.