Timeboxing in Scrum: why every event has a limit

Most plans fix the scope and let the time take care of itself. That is why they run late. Scrum reverses the arrangement at every level: the time is decided first, and the team works out what it can learn or finish inside it. The word for this is a timebox, and it is one of the framework's quietest and strongest ideas.

What a timebox is for

A timebox is a fixed period within which something has to happen. When the period ends, the activity ends, whether or not it feels complete. That sounds harsh until you look at what it does.

It forces a decision. A meeting without an end is a meeting that expands. It creates a regular rhythm, so that stakeholders know when they can see the product and the team knows when it will be asked for results. And it limits the cost of being wrong. If a Sprint is two weeks, the worst a mistaken assumption can cost is two weeks of effort.

The Guide's own reasoning is about predictability. Sprints are fixed-length events of one month or less to create consistency, and a new Sprint starts immediately after the previous one concludes. The Agile Manifesto's principle on delivery says working software should come frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.

The numbers in the Scrum Guide

The Guide sets maximum lengths for a one-month Sprint and says shorter Sprints usually have shorter events.

Refinement has no timebox in the Guide, which treats it as an ongoing activity and not an event. The Scrum Master, in the Guide's words, ensures that all events take place, are positive and productive, and are kept within the timebox.

The numbers in the SBOK

The SBOK® Guide also names time-boxing as one of its six principles. It gives a Sprint as one to four weeks and sets the meetings by a ratio: Sprint Planning at two hours per week of Sprint duration, the Sprint Review at one hour per week and the Retrospect Sprint meeting at one hour per week. The daily meeting is 15 minutes. It lists advantages of time-boxing, including a more efficient development process, less overhead and more focused teams, and it warns that arbitrary time-boxing can demotivate a team.

The two sources are in agreement on the Sprint and the daily meeting, and they differ in how they scale the others. For a four-week Sprint the SBOK's formula gives eight, four and four hours, which sits next to the Guide's eight, four and three.

A worked example: a two-week Sprint

This is an illustrative case. A team runs two-week Sprints.

Under the SBOK ratio, Sprint Planning would be up to four hours, the Sprint Review up to two, and the Retrospective up to two. Under the Guide, those are ceilings that come from the one-month figures, so a team of two weeks would expect something shorter than eight, four and three hours, and often much shorter. A team may decide: planning two hours, review ninety minutes, retrospective ninety minutes. Both sources are satisfied, because the number is a maximum and no source asks for the full length.

What matters in practice is how the team uses the box. Planning that ends at the two-hour mark with a Sprint Goal and a plan for the first days is healthy. Planning that runs to four hours because the backlog was never refined is a symptom, and the right fix is more refinement during the Sprint and not a longer meeting.

Timeboxes that people forget

Several timeboxes do not have a name on the calendar.

The Sprint Goal is a timebox for ambition. It is the single objective for these weeks and no others.

A spike is a timebox for learning. If the team does not know how to build something, it can limit an investigation to a day, then decide with what it found. The SBOK describes a risk-based spike as an intense two to three day experiment, and suggests adding such spikes to the Prioritized Product Backlog. The Guide does not mention spikes, and neither source requires them.

A task is often a timebox. The Guide says the Developers often decompose Product Backlog items into work items of one day or less. That is a planning habit, and it keeps progress visible each day.

Refinement benefits from one too. The Guide gives it no limit, but many teams agree an upper bound for their own use, such as a tenth of capacity. That figure is common in practice and is not in either source.

Why fix time and flex scope

The reasoning is practical. Effort estimates are uncertain, and the uncertainty is larger the further ahead you look. A fixed scope turns that uncertainty into a late delivery. A fixed time turns it into a smaller or larger amount of finished work, and because the Product Owner keeps the backlog in value order, what falls off the end is the least valuable part. The customer gets the most important things on a known date, and that is usually what they wanted in the first place.

This also explains why the Sprint Goal matters. When the time is fixed and the content is negotiable, the goal is what keeps the negotiation honest. See writing a Sprint Goal.

Misusing the timebox

A timebox helps when it is a boundary and hurts when it is a threat.

• Cutting quality to fit. If work is not finished at the end of the Sprint, the Definition of Done does not shrink. The unfinished item returns to the Product Backlog.
• Extending the Sprint. Stretching a Sprint by two days to finish a story destroys the rhythm and hides the real velocity. The Guide's remedy is to inspect why it did not fit.
• Treating it as pressure. The SBOK warns that arbitrary time-boxing can create an apprehensive environment. A box should come from the cadence the team can sustain, in line with the Guide's note that working at a sustainable pace improves focus and consistency.
• Running events on a clock that has no purpose. A fifteen-minute Daily Scrum that is used for status reporting is on time and still useless.
• Skipping events when time is short. The opposite error. The Guide says failing to operate events as prescribed results in lost opportunities to inspect and adapt.

How to practise it

The easiest way to feel a timebox is to be inside one. In the simulator you plan a Sprint against a fixed capacity and decide what fits, which shows how a fixed frame changes the quality of a choice.