4.7 Choosing a Suitable Sprint Length

Quick Answer: Sprints are fixed length events of one month or less. That maximum is the only hard rule; there is no minimum and no prescribed default. A suitable length is the shortest one that lets the team produce a Done, valuable Increment while giving feedback often enough for the volatility of the environment. Two weeks is the common industry choice, not a Scrum rule.

Scrum Foundations Learning Objective 3.3 asks you to explain how to determine a suitable duration of a sprint. Candidates who answer "two weeks" have memorized a convention rather than learned the reasoning.

What the Scrum Guide Actually Says

Three statements carry all the exam weight:

1. Sprints "are fixed length events of one month or less to create consistency."
2. "When a Sprint's horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase."
3. "Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame."

Notice the asymmetry: the Guide argues explicitly for shorter Sprints and warns explicitly against long ones. It never argues for longer Sprints. That asymmetry is the safest default reasoning on the test.

The Factors That Determine a Suitable Length

The last row deserves a caution. "We can't finish anything in two weeks" is far more often a slicing problem than a length problem. Lengthening the Sprint to accommodate large items usually postpones the learning the team most needs, so the Scrum Master should probe the claim before accepting it.

The Trade-Off, Stated Honestly

Shorter Sprints are not free.

• In favour: more feedback loops per quarter, smaller bets, faster detection of a wrong direction, earlier value delivery, shorter recovery from a bad Sprint.
• Against: event overhead becomes a larger proportion of capacity, work must be sliced more finely, and release or compliance overhead is incurred more often.

The timeboxes scale with the Sprint, which limits the overhead concern: the maxima of 8 hours for Sprint Planning, 4 for the Sprint Review, and 3 for the Retrospective apply to a one-month Sprint, and "for shorter Sprints, the event is usually shorter." Only the Daily Scrum is fixed at 15 minutes regardless of Sprint length.

Signals That the Current Length Is Wrong

Too long, if:

• The Sprint Goal has become irrelevant before the Sprint ends.
• Mid-Sprint scope pressure is constant because stakeholders cannot wait for the next Planning.
• Planning has become speculative because nobody can forecast that far into complex work.
• Work is routinely started late in the Sprint and finished in the next one.

Too short, if:

• No meaningful Done Increment can be produced even after the team has genuinely improved its slicing.
• Event overhead consumes a disproportionate share of capacity and the team has already trimmed the events sensibly.

The Rule That Protects the Timebox

Sprint length is fixed, and a new Sprint starts immediately after the previous one concludes. Two consequences the exam tests:

• You never extend the current Sprint because work is unfinished. The Sprint ends on schedule; undone work returns to the Product Backlog.
• Changing Sprint length is a deliberate decision made between Sprints — the Retrospective is the natural place — and applies going forward, not retroactively.

That distinction is the whole point. A team that changes its Sprint length thoughtfully at a Retrospective is inspecting and adapting. A team that extends the current Sprint by three days because it is running late has abandoned the timebox, and with it the consistency the timebox exists to create.

Real-World CSM Scenario

A team on four-week Sprints reports that by week three, roughly half the Sprint Backlog no longer reflects what the business wants, and the Product Owner is under constant pressure to inject work mid-Sprint.

Those are textbook "Sprint too long" signals — the Sprint Goal is going invalid before the Sprint concludes. The Scrum Master surfaces the pattern at the Retrospective and the team agrees to trial two-week Sprints for the next three Sprints, then inspect the result. Two details make this correct Scrum: the change takes effect at a Sprint boundary rather than mid-Sprint, and it is framed as an experiment to be inspected rather than a permanent decree. If two weeks proves too tight because items cannot be sliced, that finding is itself useful — it points at slicing skill, which is a coaching problem the team can actually solve.