A timebox in Scrum is a maximum, not a target. Every one of them exists to stop a specific failure, and knowing which failure each is guarding against answers far more exam questions than the numbers do on their own.
The Sprint, one month or less
The Sprint is the container for everything else, and it is fixed at a month or less. The limit is there because Scrum is empirical, and empiricism needs inspection often enough that a wrong assumption is caught while correcting it is still cheap. A month is the longest anyone thought a team could go without inspecting a real Increment.
Once a length is chosen it does not move. A Sprint that gets extended to fit unfinished work destroys the only honest signal the team has about how much it can actually complete, and the next forecast is built on a number that was quietly adjusted.
Shorter Sprints are always available, and they buy more learning cycles 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 you remember 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 against planning that keeps refining detail it cannot yet have. Beyond a point, more planning does not reduce uncertainty about complex work, it only defers the moment the team learns something by building.
The Daily Scrum, fifteen minutes
Fifteen minutes is the one figure that does not scale with Sprint length, because the event replans a single day and a day is the same in a one week Sprint as in a one month one.
The limit is doing something specific. The Daily Scrum is for the Developers to inspect progress towards the Sprint Goal and adapt the plan, and a session long enough to solve the problems it surfaces stops being a replan and becomes a working session that everyone else sits through. Problems raised are taken away and dealt with afterwards by the people they concern.
The Sprint Review and the Sprint Retrospective
The Sprint Review is at most four hours for a one month Sprint. It is a working session where 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, which produces applause rather than adaptation.
The Sprint Retrospective is at most three hours for a one month Sprint. It closes the Sprint by inspecting how the work went and choosing improvements. Its limit exists to force a decision. A retrospective without a boundary tends to keep surfacing material and end with a list nobody has committed to.
Reading a timebox correctly
Each of these numbers is a maximum for a one month Sprint, and events are usually shorter when the Sprint is shorter. Finishing early is not a failure, and a team that consistently fills the whole box is usually running the event for the wrong purpose.
What is never negotiable is the Sprint boundary itself. Events inside it can be brief, and the Sprint ends when it ends.
What a timebox is actually for
A timebox is a risk limit rather than a rule about punctuality. What the fixed length buys is a ceiling on how much can be spent before somebody checks, which is the reason an empirical framework bothers with fixed durations at all.
Take the Sprint. 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 point at which those assumptions meet a real Increment and the reactions of real people. 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 rather than an administrative one. Shorter Sprints produce more of those decision points and put a smaller amount at risk in each, which is why a team working in unfamiliar territory shortens the Sprint instead of lengthening it to fit the work.
What a timebox does not do is worth stating just as plainly, because most of the wrong answers live there.
It does not guarantee the Developers finish everything in the Sprint Backlog. A forecast stays a forecast, and items that are not Done return to the Product Backlog for the Product Owner to reorder.
It does not 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.
It does not produce a report. The Sprint boundary produces an inspectable Increment and a set of decisions taken from it, and the Guide asks for no document at the end of any event.
Each of those answers mistakes a container for a commitment about its contents. The timebox promises when the inspection happens and never what will be inside it.