The Sprint: a fixed container for turning ideas into value

Most plans that fail do so quietly, over months, with nobody checking until the end. A Sprint is an attempt to make that impossible. It is a short, fixed stretch of time at the end of which something usable exists and everyone looks at it honestly.

What the Guide says

The Scrum Guide calls Sprints the heartbeat of Scrum, where ideas are turned into value. They are fixed-length events of one month or less, to create consistency, and a new Sprint starts immediately after the conclusion of the previous one. There is no gap between them for planning or recovery.

Everything the team does to achieve the Product Goal happens inside Sprints: Sprint Planning, the Daily Scrums, the Sprint Review and the Sprint Retrospective. The Sprint is the container for all the other events, which is why the Guide describes it as the one that holds the rest.

Four rules for the duration of a Sprint

During the Sprint, the Guide sets four conditions.

1. No changes are made that would endanger the Sprint Goal.
2. Quality does not decrease.
3. The Product Backlog is refined as needed.
4. Scope may be clarified and renegotiated with the Product Owner as more is learned.

Read them as a pair of limits and a pair of freedoms. The limits protect the goal and the quality bar. The freedoms recognise that planning at the start of a Sprint is based on incomplete knowledge. The team can discover that a story is bigger than thought, drop the least important item and keep the goal. What it should not do is add new work that competes for the same capacity, or cut corners on testing to protect the date.

Why fixed length

A Sprint that ends when the work is finished sounds sensible and does not work. Without a fixed end, there is no moment at which the team must inspect and adapt, and "nearly done" can last for weeks. A fixed length does three jobs.

• It limits risk. The Guide says each Sprint may be considered a short project, and that shorter Sprints generate more learning cycles and limit the cost and effort at risk to a smaller time frame.
• It makes planning honest. The team learns how much it can finish in a Sprint of this length, and forecasts improve with experience. That only works if the length stays the same. See how velocity gets misused.
• It creates a regular decision point. At least every calendar month, someone sees a working Increment and can decide whether to carry on, change course or stop.

Choosing a length

The Guide's cap is one month. It also warns about the other end: when a Sprint's horizon is too long, the Sprint Goal may become invalid, complexity may rise, and risk may increase. Within that range, the right choice depends on how fast your situation changes and how long it takes to produce something worth inspecting.

The SBOK® Guide gives more specific advice, which the simulator reflects. Its Sprint is a time-boxed iteration of one to four weeks, with two or three weeks the most common. If the requirements are poorly defined, or significant change is expected soon, it suggests one to three weeks, so the team can clarify requirements and adjust at the end of each Sprint. If requirements are stable and major change is not expected, it allows a Sprint of up to six weeks in some cases. It adds that the likelihood of change is not the only factor, and that the planned release date and the time needed to produce a deliverable also count.

Two practical points apply either way. First, keep the length stable. The SBOK warns against moving from three weeks to two to four from one Sprint to the next, because the change resets all tracking and earlier velocities may become useless for forecasting. Second, do not pick a length because it matches the calendar. A one-month Sprint fits a monthly business cycle and no other reason.

Timeboxes inside the Sprint

Each event has a maximum length, proportional to the Sprint. The Scrum Guide sets maximums for a one-month Sprint: eight hours for Sprint Planning, fifteen minutes for the Daily Scrum, four hours for the Sprint Review and three hours for the Retrospective. For shorter Sprints, the events are usually shorter.

The SBOK sets similar proportions, with a slightly different split. Its planning meeting is time-boxed to two hours for each week of Sprint (eight hours for a four-week Sprint), and its Sprint Review and Retrospect Sprint meetings to one hour for each week. If you are using both documents, the safe course is to treat each figure as a ceiling and not a target. A team that finishes in half the time has not failed.

Can a Sprint be cancelled?

Yes, in one circumstance. The Guide says a Sprint could be cancelled if the Sprint Goal becomes obsolete, and that only the Product Owner has the authority to cancel it. The Sprint Goal might go stale because the company changed direction, the market shifted, or a technology choice proved unworkable.

Cancelling should be rare, because it throws away a Sprint of learning and disrupts the rhythm that gives the framework its value. It is not a remedy for a Sprint that is going badly. If the goal is still valid but the team is behind, the usual response is to renegotiate scope with the Product Owner, not to stop.

How a Sprint ends and the next begins

The Guide's wording is precise: a new Sprint starts immediately after the conclusion of the previous Sprint. The Sprint Review is the second to last event and the Retrospective concludes the Sprint, so the last stretch has a fixed order: show and discuss the Increment with stakeholders, then look at how the team worked, then begin Sprint Planning for the next one.

That sequence matters. The review's conclusions feed the Product Backlog, which feeds the next Sprint Planning, and the retrospective's improvements may go into the next Sprint Backlog. A team that finishes the retrospective on Friday afternoon and plans on Monday morning has lost no time and can carry both conversations straight into the plan. A team that inserts a "planning week" loses the thread.

Common mistakes

• Adding work in the middle. A new request is not a reason to extend or restart a Sprint. It goes on the Product Backlog and is considered at the next Sprint Planning, unless it threatens the goal, in which case the Product Owner decides.
• Gaps between Sprints. A "planning week" between Sprints breaks the continuous rhythm the Guide describes.
• Changing the length to match the work. If the team is behind, a longer Sprint hides the problem. Keeping the length shows it.
• Dropping events when busy. The Retrospective is first to go, and the one most worth keeping.
• Calling a time-boxed phase a Sprint without a goal. If there is no Sprint Goal and no usable Increment at the end, you have an iteration in name only.

The Agile Manifesto principle on this point is to deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.

How to practise it

Choosing a length is a real decision with a cost, and you only feel it by living with it. In the simulator, you set the Sprint length at release planning, from one to four weeks, and the choice sets how much the team can take on in every Sprint.