Sprint Retrospective Timebox Timer

READY
05:00
Step 1 / 5

Running order

  1. 1.Set the stage 05:00
  2. 2.Gather data 15:00
  3. 3.Generate insights 20:00
  4. 4.Decide what to do 15:00
  5. 5.Close the retrospective 05:00

Total 1:00:00 across 5 steps.

The Scrum Guide timeboxes the Sprint Retrospective at a maximum of three hours for a one-month sprint, with shorter sprints getting proportionally shorter events[1]. For the common two-week sprint that means up to ninety minutes, and most teams use rather less than the maximum.

A timebox is a maximum rather than a target. A retrospective that reaches useful actions in forty minutes should end at forty minutes; one that fills ninety because ninety were booked has spent fifty minutes producing nothing. The value is in the actions, not in the airtime.

The actions phase is what gets squeezed

Retrospectives reliably spend too long gathering data and generating discussion, then rush the part where the team decides what to actually change. That is exactly backwards, because the discussion is worthless without a decision attached.

Timeboxing each phase separately rather than the meeting as a whole is the fix. Reserving the last quarter for decisions, and protecting it, is what turns a retrospective from a venting session into a process improvement.

One or two actions, with owners

A retrospective that produces nine improvements produces none, because nothing with nine priorities has any. One or two changes with a named owner and a checkpoint at the next retro is the pattern that actually alters how a team works.

Reviewing the previous retro's actions at the start of the next one is the other half. Without that loop the meeting becomes a ritual, and teams stop taking the actions seriously because nobody ever asks about them.

Shorter sprints, shorter retros

The Scrum Guide scales the event with the sprint, and the reason is simply that a one-week sprint has less to inspect. Running a ninety-minute retrospective on a one-week sprint fills the time with material rather than finding it.

Forty-five minutes for a one-week sprint and ninety for a two-week sprint are the usual proportional figures, and both are ceilings rather than durations to fill.

Scrum Guide maximums by sprint length[1], with a proportional phase split for a 90-minute retro.

Retrospective timeboxes and phase split
Sprint length Retro maximum Typical actual
1 month 3 hours 90–120 min
3 weeks ~2h 15m 75–90 min
2 weeks ~90 min 60–75 min
1 week ~45 min 30–45 min
Phase: set the stage 5 min
Phase: gather data 15 min
Phase: generate insights 20 min
Phase: decide actions 15 min
Phase: close 5 min
  • A timebox is a maximum, not a target — a retro that reaches good actions in forty minutes should end there.
  • One or two actions with a named owner beats nine. Review the previous retro's actions at the start of the next.

Source: The Scrum Guide — Sprint Retrospective timebox

Sources

  1. The Scrum Guide — Sprint Retrospective timebox , Scrum.org / Ken Schwaber and Jeff Sutherland (Verify current edition) — accessed 2026-07-28

🔗 Related Timers

❓ Frequently Asked Questions

How long should a sprint retrospective be?
The Scrum Guide sets a maximum of three hours for a one-month sprint, scaling down proportionally — around ninety minutes for a two-week sprint. Most teams use considerably less than the maximum.
Is the timebox a target?
No, a maximum. A retrospective that reaches useful actions in forty minutes should end at forty minutes; one that fills ninety because ninety were booked has spent fifty producing nothing.
Which part of a retro gets squeezed?
Deciding what to change. Teams reliably spend too long gathering data and discussing, then rush the decisions — which is backwards, since discussion without a decision attached is worthless.
How do I protect the actions phase?
Timebox each phase separately rather than the meeting as a whole, and reserve the last quarter for decisions. That is what turns a retrospective from venting into process improvement.
How many actions should come out of a retro?
One or two, each with a named owner and a checkpoint at the next retro. Nine improvements produce none, because nothing with nine priorities has any.
Why review the previous retro's actions?
Without that loop the meeting becomes a ritual. Teams stop taking actions seriously when nobody ever asks about them, and the retro degrades into a recurring conversation that changes nothing.
TheTimerLab