So many meetings in Scrum!
I’m a developer and I like Scrum. Not every developer does. A complaint I sometimes hear is the following:
We spend so much time in meetings that I don’t get around to writing code!
If you have - or are confronted with - such a complaint, I have some tips for you to take into consideration
Time spent on Scrum events
How much time should a developer officially spend on meetings?
Let’s start with the facts. The Scrum guide is pretty explicit about Scrum Events, but the totals may not be immediately evident. I’ll start from the assumption that one works 8 hours a day, 5 days a week. More on that later.
-
Daily Scrum: 15 minutes daily scrum per day.
-
Sprint Planning: 8 hours for a 1 month sprint.
-
Sprint Review: 4 hours sprint review for a 1 month sprint.
-
Sprint Retrospective: 3 hours for a 1 month sprint.
-
Backlog Refinement: Not an event in the sense of a single meeting, but 'spend 10% of your time on backlog refinement'.
Let’s put that in a table and calculate.
| Event | Hours per 4-week sprint | Hours per day | Percentage | Calculated hours per week |
|---|---|---|---|---|
Daily Scrum |
0:15 |
01:15 |
||
Sprint Planning |
08:00 |
02:00 |
||
Sprint Review |
04:00 |
01:00 |
||
Sprint Retrospective |
03:00 |
0:45 |
||
Backlog Refinement |
10% |
04:00 |
||
Total time spent |
09:00 |
In total, in a 40 hour workweek, you can expect to spend nearly a maximum of 9 hours on Scrum events. That’s nearly a quarter of your time.
Sounds like a lot, right?
Well, maybe. There are some things to take into consideration.
Backlog refinement is not one meeting
The 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 goal: to understand the work ahead of you
| The 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 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 grok.
-
Your team is familiar with the kind of work. 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.
-
Your team communicates continuously. You don’t need to have a 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 10 hours will mean a relatively higher percentage of your time.
Daily scrum, sprint planning, review, and retrospective are events that take the same amount of time whether you work 24, 32, 36 or 40 hours a week.
As for backlog refinement, you’ll have to decide as a team what '10% of your time' should boil down to. But 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.
You probably don’t need that other meeting
Before accepting any other kind of meeting, 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.
That said:
-
Managers can attend the sprint review.
-
Managers can read up on your action points regarding process following from your 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 can and will hamper progress. They should be addressed and solved by a Scrum Master (in team) or Agile Lead (organisation surrounding the team). |
-
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 let yourself be lured into roadmap and forecast meetings with stakeholders. Don’t be tempted to commit hours, story points or other measures of velocity or cost that you’ve been using inside your team.
| These are questions about the product backlog. That’s what the Product Owner is for. Let them deal with it. |
The Product Owner can ask developers for advice, of course. That would typically fall into the 'backlog refinement' category, which we already planned time for.
Closing note: Is not writing code time wasted?
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, that is so crucial.
| It is better to write one line of code that helps deliver value than to have 1000 lines of code that don’t. |
Of course the other extreme is getting stuck in analysis paralysis and big up front design. Sometimes you won’t know the value of an idea until you’ve implemented it and measured it in production, so be prepared to experiment and learn!
