Sprint
iteration / two-week sprint / sprint cycle / can we add this mid-sprint
A sprint is a fixed length block of development work, one month or less in the Scrum Guide and usually one to four weeks in practice. The fixed length is the point: it is what makes a completion estimate possible, and it decides what can be changed once the block has started.
The Scrum Guide calls sprints fixed length events of one month or less, held to that length to create consistency, and adds that a new sprint starts immediately after the conclusion of the previous one. There is no gap between them. Agile Alliance, which uses the older word iteration for the same thing, puts the usual range at one to four weeks and notes that the two terms are now used interchangeably.
The fixed length is not administrative tidiness. Agile Alliance gives the reason plainly: it is what lets a team take its velocity and the amount of work remaining and produce a usually accurate, though not very precise, estimate of how long the project has left. Variable-length blocks make that arithmetic impossible, which is why a team that abandons the rhythm also loses the ability to tell you when it will be finished.
The rules for what happens inside one answer the question owners actually have. During a sprint, the Scrum Guide says no changes are made that would endanger the sprint goal, quality does not decrease, the backlog is refined as needed, and scope may be clarified and renegotiated with the product owner as more is learned. So the answer to whether something can be added mid-sprint is not a flat no. It is that it depends on the goal, and it goes through the product owner.
One more line settles a common dispute: only the product owner has the authority to cancel a sprint, and the Scrum Guide contemplates that only when the sprint goal has become obsolete. It also frames the unit usefully, saying each sprint may be considered a short project.
In practice
Two questions make a sprint legible from the outside. What is the goal of this one, and what would endanger it. A request that fits the goal is usually a conversation. A request that replaces the goal is a request to abandon a short project already underway, and it is worth knowing that is what you are asking.
Not the same as
- A deadline
- The length is fixed, but what fits inside is decided at the start and can be renegotiated as more is learned.
- A phase
- The Scrum Guide has one sprint beginning the moment the last one ends, with planning, review and retrospective all inside it.
Why it matters to you
Almost every argument about a development project is really about when something can change. Fixed length blocks give a clear answer instead of a negotiation: the goal is protected, the detail is not, and one named person arbitrates. That is also what buys you a forecast, since an estimate of remaining time depends on a steady rhythm to measure against.
What to ask or check
- 01What is the goal of the current sprint, and does my request endanger it?
- 02How long are the sprints here, and has that length actually held?
- 03Who is the product owner, since scope changes and cancellation both run through them?
What people get wrong
That nothing can change once a sprint starts. The Scrum Guide protects the sprint goal, not the detail: scope may be clarified and renegotiated with the product owner as more is learned.
Red flags
- Sprint lengths that move around, which removes the basis for any forecast.
- Scope changes arriving without the product owner, who is the person the rules put them through.
- A sprint with no stated goal, which leaves nothing to judge a request against.
Who owns it
The product owner, explicitly. The Scrum Guide routes scope renegotiation through them and gives them alone the authority to cancel a sprint.
Where you will see it
In any status call with a development team, and in the invoice cadence that usually follows it.