The Right Timing for Scrum Events
It’s done pretty quickly: crank up your calendar tool of choice, add a new event, throw in a bunch of your colleagues. There you go. You just created a meeting. And maybe a mess.
Looks pretty straight forward. Start the day with a Daily, end it with other meetings.
This is how we used to have our Scrum Events in one of my recent projects. Nothing wrong here, one could say. Maybe a little unconventional to have the Sprint Review and Retrospective on Monday. This was due to the fact that the client couldn’t make it on Fridays to the Sprint Review. So we moved that to Monday. Good job everyone: Dailies at the start of the day, other meetings close to the end of the day. Pretty straight forward.
Looks familiar?
Until one day the Scrum Team asked for two week sprints, instead of one week sprints. I’m a huge advocate on one week sprints, so I was curious. They said that we had too many meetings. I asked a few questions and it became pretty clear that the problem wasn’t the amount of meetings we had, but the timing for the meetings.
Especially Mondays and Thursdays made the team feel unproductive. Why? Too many context switches:
- 09.30 — start working
- 10.00 — have a daily
- 10.15 — a little more work
- 12.30 — go to lunch
- 13.30 — a bit more work
- 16.45 — have a meeting or two
- 18.00 — maybe a little more work — or lets just call it a day
Do you have a lot of days like this?
On those days the team never really got to the point of being "in the zone". There were too many interruptions.
Five minutes later we got to this pattern:
Now we have all Scrum Events at the start of the day so that the team can focus for the rest of the day.
That has been working pretty well for everyone. Mondays have the Planning, Sprint Review and Retrospective as consecutive meetings. Thursdays have the Daily Scrum and the Backlog Refinement butt up against each other. This way all Scrum Events are done with the start of the day and the team can focus for the rest of the day.
Often times it’s the symptoms that we are trying to fix instead of the root cause.
Take Aways
- Make sure that Scrum Events (and other types of meetings) are grouped instead of scattered. That helps everyone to focus and prevents unnecessary context switching.
- As a Scrum Master it’s always worth to ask questions in order to understand the underlying problem. Especially when it affects the process itself. Often times it’s the symptoms that we are trying to fix instead of the root cause.
Where to put Sprint Reviews and Retrospectives
Let me get back to the awkward placement of the Sprint Review. Even though it started out as a compromise, I think I will stick to the "Sprint Reviews on Mondays" pattern in future projects.
I’ve seen the issue a lot: Friday used to be a pretty hectic day and it always seemed like there were a couple of hours stolen from the team each week. The stories that the teams are tackling on Friday needed to be done at 3 p.m. at the latest, so that the Product Owner had the chance to review them. If the Product Owner found an issue that the team had to fix, there was always the risk that the story couldn’t be done until Sprint Review.
Having the Sprint Review and the Retrospective on Monday morning, allows the team to focus longer on their work and reduces the risk of unfinished stories close to Sprint Review. I remember a few sketchy deployments right before Sprint Review when I was a developer myself, working in Scrum Teams.
What do you think about Review & Retro on Mondays?
There might be disadvantages as well
- Having a weekend between a Sprint Review and Retrospective which blurs the memory
- Not a lot of time between the Sprint Review and the Sprint Planning, in case the Review results in changes being made to the upcoming Sprint Backlog
- The team might be tempted to put in extra work at the weekend which is unsustainable if it happened regularly
- That is a lot of meetings for a day — especially for a two (or more) week sprint
Take Away
- Always question everything and try to optimize productivity. I for myself never really questioned the Sprint Review and Retrospective timing. It seemed obvious to do it on Friday afternoon. It took a client that couldn't make it to let me reconsider.
Conclusion
Getting the timing for meetings right is crucial for the teams happiness – no one likes to feel unproductive. I assume there is an effect on productivity, too. But I don’t have any data to quantify that.
The obvious thing to do is making sure that meetings are grouped together to avoid meeting gaps. But there are a lot more things to consider.
Iterating on the teams calendar for the sake of team happiness and productivity is a smart thing to do.
I’d love to hear more thoughts and experiences on this matter. Clearly, there is never only one way of doing things and a different project or team might call for a different approach. How do you guys handle these things and what have you learned?