Every Scrum event has a maximum allowable time period to carry it out, called a timebox. When I tell someone that the Sprint Planning event is timeboxed at eight hours, I usually receive shocked looks. “Eight hours!” they say, “That’s horrible!”
There seems to be a misunderstanding about applying timeboxes in Scrum.
While Scrum events have a maximum amount of time, they do not have a minimum amount of time. Once the team covers what it needs to, the event concludes. The Scrum timeboxes are there to guard against the team spending too much time planning and reviewing rather than doing the work of the Sprint. They make your team more effective.
I have attended just one Sprint Planning event that took the full eight-hour timebox. Most are shorter. At the end of the eight hours, the team still wasn’t done with everything they had hoped to accomplish! One of the Developers asked if we should continue the discussion the next day. The answer was NO because the team had reached the timebox.
I remember the sigh of relief the rest of the team gave when they heard that we would not continue Sprint Planning the next day. Instead, on the day following our marathon Sprint Planning event, the Scrum Team just got started working, and the remainder of the Sprint Backlog emerged during the Sprint.
Let’s look at all of the event timeboxes and how they make Scrum Teams more effective.
Scrum Event Timeboxes
The following table shows the five events in Scrum and their timeboxes.
The Sprint - one month or less
The first event in Scrum is the Sprint itself. The Sprint isn’t a meeting; it’s a container for all the other events. The Sprint has a timebox of one month because, in a complex environment, humans cannot plan in any level of detail longer than a one-month horizon. Also, the short time horizon shrinks the feedback loop so that at least once per month, the Scrum Team reviews the increment with its stakeholders and collaborates on what to do next. The shorter timebox has the benefit of limiting the investment in the Sprint to just one month's-worth of time and resources.
A misconception Scrum Teams have about the duration of the Sprint has to do with risk. Most people think that in riskier environments, the Sprint should be longer. The reverse is true. When unexpected changes in the environment are likely, shorter Sprints mean the team can re-plan frequently to take those changes into account. If your stakeholders often request changes, for example, or your technology is unknown or risky, a shorter Sprint allows you to respond more quickly to these uncertainties.
Sprint Planning (eight hours or less)
The next event in Scrum is the Sprint Planning event, where the Scrum Team plans the work for the upcoming Sprint. As discussed above, this event is limited to eight hours because anything more than that is wasteful. Scrum is based on empiricism (making decisions based on what is known) and lean thinking (reducing waste and focusing on essentials). Sprint Planning that goes beyond eight hours is not focused on the essentials!
Daily Scrum (15 minutes)
Next is the Daily Scrum, which is a short, 15-minute daily event for the Developers to collaborate. If Developers identify impediments requiring further discussion, they can hold that discussion after the Daily Scrum and include only those who need to be there. Again, timeboxing this event to just 15 minutes eliminates waste.
Sprint Review (four hours or less)
Near the Sprint’s end, the Scrum Team and its stakeholders hold the Sprint Review to discuss what the team delivered in the increment and decide what to do next. The Sprint Review has a timebox of four hours.
Sprint Retrospective (three hours or less)
Towards the end of the Sprint, the Scrum Team and its stakeholders gather for the Sprint Retrospective to identify and eliminate inefficiencies. The timebox for the Sprint Retrospective is three hours, during which the Scrum Team identifies at least one improvement they can make to improve their processes, the way they work together, or their Definition of Done.
Typical Calendar for a one-week Sprint
At first glance, it seems the team will hold many meetings to accommodate the Scrum events. But that’s not the case when you realize that the events take place over the course of the Sprint; they don’t take place all in one day.
Let’s look at a typical one-week Sprint.
The calendar would start with a one-hour Sprint Planning. Now, while a Sprint Planning event is timeboxed at eight hours, shorter Sprints usually require less time. In my experience, a typical one-week Sprint usually has a one-hour Sprint Planning event, assuming the team is doing a good job refining the Product Backlog during the Sprint.
During the Sprint, the team will have a Daily Scrum, taking 15 minutes each day. Let's assume that the Scrum Team takes the full 15 minutes every day. That means they would spend one hour per Sprint for this event, assuming they wouldn’t have one on the first day of the Sprint.
Toward the end of the Sprint, the Scrum Team will conduct a Sprint Review. While this event is timeboxed at four hours, shorter Sprints require less time. Let’s assume a one-hour Sprint Review, which would be reasonable for a team in our scenario.
The Sprint ends with the Sprint Retrospective. This final event in Scrum has a three-hour timebox, but for a typical one-week Sprint, we can assume a half-hour per Sprint at the Sprint Retrospective.
In total, you will find that a typical team conducting a one-week Sprint spends just 4.5 hours on the Scrum events. If we add a one-hour refinement meeting (which is not an event in Scrum but is a common practice), that is just 5.5 hours per week.
Typical Calendar for a two-week Sprint
For comparison, let’s look at a two-week Sprint. Generally, our timeboxes will be a little longer for a two-week Sprint, but surprisingly, the overall time is not any longer than our one-week scenario.
A typical Scrum Team conducting a two-week Sprint cadence might spend two hours in Sprint Planning. They will run a Daily Scrum for 15 minutes each day. Assuming that the team does not conduct a Daily Scrum on the first day of the Sprint, we arrive at a total of 2.25 hours for the Daily Scrum. The team might spend two hours in the Sprint Review and one hour in the Sprint Retrospective. All told, the Scrum team using a two-week Sprint will meet 9.25 hours per two-week Sprint on the Scrum events plus time for a refinement meeting.
If you divide the total time by two to see how it compares to a one-week Sprint, you find that, on average, a team conducting a two-week Sprint will consume 4.6 hours per week on the Scrum events plus refinement. The slight increase comes from the team holding the Daily Scrum one additional time in a two-week Sprint compared to the team running a one-week Sprint.
Conclusion
The timeboxes in Scrum are there to save time, preventing teams from getting stuck in an endless loop of discussion. Because Scrum is used in complex environments where more is unknown than known, Scrum Teams often have to learn what will work based on their experience. That means their time is better-used diving into the work rather than planning and reviewing it in great detail. Timeboxes reinforce that reality.