A timebox in Scrum is a maximum length, and the 2020 Guide sets one for the Sprint and for every event inside it. An event that achieves its purpose early is finished, so each figure is a ceiling and never a duration the team has to fill. The numbers are short enough to memorise, which is where most candidates stop, but every limit was chosen to prevent a particular failure and the failure is what the scenario questions are built on.
The Sprint, one month or less
The outermost limit is the Sprint, which contains every other event, and Scrum fixes it at one month or less. That ceiling exists because Scrum is empirical, and an empirical process needs inspection often enough that a wrong assumption is caught while correcting it is still cheap. A month is as long as the framework will let a team go without putting a real Increment in front of somebody, since beyond that point the team is working on belief alone.
Once a length is chosen it does not move. A team that adds three days to finish a payments migration keeps the work and loses the measurement, because the only honest signal it had about its own capacity was how much fitted inside the fixed length. Every forecast after that rests on a number somebody quietly adjusted, and nobody reading the forecast can tell.
Changing the length between Sprints is a different matter, because shorter Sprints stay available at any time, and a team that wants more inspection points can take them and confine the cost of being wrong to a smaller window.
Sprint Planning, up to eight hours
Sprint Planning is timeboxed to a maximum of eight hours for a one month Sprint, and it is usually shorter for shorter Sprints. Eight hours sounds generous until the candidate remembers what has to happen inside it. The Scrum Team works out why the Sprint is valuable, crafts a Sprint Goal, selects the items that will serve it and produces enough of a plan to start.
The limit protects the team from planning that keeps refining detail the work has not yet produced. Past a certain point more planning does not reduce uncertainty about complex work, because the uncertainty sits in what the code will do once it runs and no plan can settle that. The extra hours only delay the moment the team learns something by building.
The Daily Scrum, fifteen minutes
The Daily Scrum is where that learning reaches the plan, and fifteen minutes is the one figure in Scrum that does not scale with Sprint length. The event replans a single day, and a day is the same length in a one week Sprint as in a one month one, so there is nothing for the figure to scale against.
That limit is doing a specific job. The Daily Scrum exists for the Developers to inspect progress towards the Sprint Goal and adapt the plan for the coming day. A Daily Scrum long enough to solve the problems it surfaces has stopped replanning and turned into a working session the rest of the team sits through, so problems raised in it are taken away and settled afterwards by the people they concern.
If the Developers find that the search service has started returning stale results, the fifteen minutes are where they say so and decide what the day now looks like, and the two who will trace the cause do that afterwards.
The Sprint Review and the Sprint Retrospective
The same reasoning sets the ceilings on the two events that close the Sprint. The Sprint Review is at most four hours for a one month Sprint. It is a working session in which the Scrum Team and stakeholders inspect the Increment and discuss what to do next, and the Product Backlog is adjusted as a result. Four hours is the ceiling because a review that runs longer has usually turned into a presentation, and a presentation ends with everybody agreeing it went well while the Product Backlog looks exactly as it did before.
The Sprint Retrospective is at most three hours for a one month Sprint, and it closes the Sprint by inspecting how the work went and choosing what to improve. Its limit exists to force a decision, because a retrospective with no boundary keeps surfacing new material and ends with a list nobody has agreed to own.
Reading a timebox correctly
Each of those numbers is a maximum for a one month Sprint, and every event except the Daily Scrum is usually shorter when the Sprint is shorter. Finishing early is therefore no failure at all, while a team that consistently fills the whole box is usually running the event for something other than its purpose.
The exception to all of that flexibility is the Sprint boundary itself. Events inside the Sprint may be as brief as their purpose allows, while the Sprint itself ends on the date it was always going to end on.
Holding all of those limits, from the Sprint boundary down to the fifteen minutes, falls to the Scrum Master, who ensures that all Scrum events take place and are kept within the timebox. Holding the number is only half of that service, though, because an event can finish on time and achieve nothing. When a Daily Scrum ends at fifteen minutes with no plan for the next day, the limit has held and the event has produced nothing, so the question for the Developers is what the fifteen minutes went on.
What a timebox is actually for
A timebox is a risk limit. The fixed length puts a ceiling on how much effort can be spent before somebody inspects the result, and that is the whole reason an empirical framework sets fixed durations at all.
The Sprint shows this most clearly. A team working towards a Product Goal is acting on assumptions about what will help, and some of those assumptions are wrong. A fixed length Sprint caps the cost of being wrong at one Sprint's effort, and it guarantees a date on which those assumptions meet a real Increment and the reactions of real people. A team that spends two weeks building a saved card feature for a mobile checkout learns at the Sprint Review whether anybody saves a card. A team with no Sprint boundary spends three months on the same feature before it finds out. That is what makes it possible to inspect progress towards the Product Goal and decide, on evidence, whether to carry on in the same direction or change it.
Sprint length is therefore a risk decision. Shorter Sprints produce more of those decision points and put a smaller amount of effort at risk in each one. That is why a team moving a billing job off a legacy service for the first time has a reason to shorten the Sprint while the ground is unfamiliar. Teams are usually tempted the other way, because stretching the Sprint until the work fits feels like progress and costs the team the inspection it most needs.
That is what a timebox buys. Most of the wrong answers in this area come from three assumptions about what else it promises, so each one is worth stating plainly.
A timebox does not guarantee that the Developers finish everything in the Sprint Backlog. A forecast stays a forecast, so whatever has not met the Definition of Done returns to the Product Backlog for the Product Owner to reorder.
Nor does a timebox mean the Sprint runs until testing is complete, or until the Product Owner has verified the work. The Sprint ends on its date, and anything short of the Definition of Done is simply not part of the Increment.
A timebox also produces no report. The Sprint boundary produces an inspectable Increment and the decisions taken from it, and the Guide asks for no document at the end of any event.
Each of those three answers mistakes a container for a commitment about its contents, because a timebox promises when the inspection happens and never what will be inside it.