This is John, and John is a developer that went through one of my Scrum classes recently.
John works for a company that is using Scrum, and they are doing 4-week Sprints. John told me that he works at a sustainable of about 40 hours per week, so over the course of a 4-week Sprint, he works about 160 hours.
John told me that he doesn’t have a lot of free time. Actually, he said he has almost no free time. He spends most of his time in meetings and just trying just trying to remember what he’s supposed to be doing. John asked me, “Why does Scrum have so many meetings?"
I asked John what meetings he has been attending, and he listed off the Scrum events:
- Sprint Planning
- Sprint Review
- Sprint Retrospective
- Daily Scrums
John and I talked about the time-box for each event and added up those hours. The total of all of the time-boxes in a 4-week Sprint is 20 hours. Now, these are time-boxes, so the time could be shorter, but this this is the maximum amount of time that should be spent in Scrum events in a 4-week Sprint.
Also, time-boxes are normally scaled down proportionately for shorter Sprints. For example, Scrum teams that use 2 week Sprints usually time-box Sprint Planning to 4 hours, although they could technically use the full 8 hours if they wanted to. The math that we’re about to do will apply to any Scrum team regardless of how long your Sprints are.
But back to the story, after John and I added up the hours of the Scrum events, John said, “Yeah, but that’s only if someone is on one Scrum team. No one at our company does that.” So I began white-boarding how much time is spent in Scrum events when someone is on multiple Scrum teams. I started with the number of teams, John’s capacity working at a sustainable pace, the total hours spent in Scrum events, and the number of hours left after attending Scrum events.
Let’s say that John could only be on one Scrum team. How much time does that leave him to work? Again, John has 160 working hours during the 4-week Sprint. 20 of those hours would be spent in Scrum events.
Also, I just want to say this again - this is for a 4-week Sprint - teams that are using shorter Sprints usually use shorter time-boxes (although they don’t have to).
So John is left with 140 hours of working time after attending Scrum events, but that’s only if John is on 1 Scrum team. Also, I haven’t even talked about Product Backlog refinement yet. Refinement usually consumes no more than 10% of the capacity of the Development Team, so let’s just use 10% to make this math easy. 10% of 160 hours is 16 hours.
What if John was on 2 Scrum teams? Actually, what if John on 3 Scrum teams. Or 4? Or 5? What would that look like?
John’s eyes got wide and a smirk came across his face as I drew this on the whiteboard. He began to realize why he had very little free time… John was on 3 Scrum teams.
How much time does John have left after attending Scrum events and doing Product Backlog refinement?
With John being on 3 Scrum teams, he doesn’t have much time left. But I’ve met people that have been on as many as 5 Scrum teams - according to some simple math, they’re probably not working at a sustainable pace, or they’re not able to fully participate as a team member.
Having one person be a member of 3, 4, or 5 Scrum teams is probably too many. Even being on 2 Scrum teams dramatically lowers the amount of working time someone has during a Sprint. So if you want to strive for productivity and allow people to focus, Scrum team members should probably only be on one team.
I mentioned that John is a developer, so this math obviously applies for Development Team members. But what about Product Owners and Scrum Masters?
Product Owners and Scrum Masters do not have to attend Daily Scrums, so that cuts out some time in Scrum. But even though Product Owners and Scrum Masters do not have to attend the Daily Scrum, they often do as their Scrum teams can find it beneficial.
Another thing to consider is scaled Scrum. When scaling Scrum, there should be one Product Owner per product, and there will be multiple Scrum Teams working on that product. Depending on how Scrum is scaled and how many teams are working on one product, a Product Owner could serve as Product Owner while being on many Scrum teams.
And what about Scrum Masters? Scrum Masters have 3 primary areas of service: to their Development Team, to their Product Owner, and to the organization. In a scaled environment, Scrum teams may share many impediments across those layers of service, so a Scrum Master could achieve “economies of scale” by being on multiple Scrum teams. But by doing so, they limit their opportunity to actually spend time with their teams. And if they do spend time with their teams, they are losing time that could be spent resolving impediments.
While Scrum does not prevent individuals from being members of multiple Scrum teams, the loss in productivity from context switching and time in meetings should be taken into account, especially for Development Team members.