Sprint

A sprint is a fixed-length period, conventionally between one and four weeks, during which a team completes a set of work intended to produce a usable increment of the product. The length is held constant across sprints so that the team develops a reliable sense of its own capacity and so that planning, review, and adaptation happen on a predictable rhythm.

The purpose of the time-box is to create regular points at which direction can be reconsidered with evidence. At the end of each sprint there is something to inspect, which allows stakeholders to react to what actually exists rather than to a plan, and allows the team to adjust based on what was learned. Without a working increment to inspect, the boundary is merely a calendar marker and the adaptation the structure exists to enable does not occur.

Treating the sprint as a deadline rather than as a container is the most damaging common misunderstanding. When work committed at planning is not complete, the appropriate response is to carry it forward and to examine why the estimate was wrong, not to compress testing, skip review, or extend the sprint. Teams that consistently sacrifice quality to close a sprint accumulate defects and technical debt at a rate that eventually consumes their capacity entirely, and the pattern is usually established by external pressure rather than chosen.

Scope stability during the sprint is what makes any of this work, and it is the discipline most frequently violated. The team commits to a set of work on the understanding that it will not change mid-sprint, which is what allows them to plan and focus. Organizations that inject urgent work continuously have removed the commitment, and the team is effectively working reactively while performing the ceremonies of planned delivery.

The sprint goal is a frequently omitted element that changes how the period functions. Rather than a list of unrelated items, a goal states what the sprint is trying to achieve, which gives the team a basis for making trade-offs when reality diverges from the plan. With a goal, a team can drop a lower-value item and still succeed; with only a list, every item is equally mandatory and any shortfall is a failure.

Length involves a real trade-off. Shorter sprints provide more frequent feedback and limit how far a team can go in the wrong direction, at the cost of proportionally more time spent in planning and review. Longer sprints reduce that overhead but delay the feedback and allow more to be built before it is validated. Two weeks has become the common compromise, though the right answer depends on how quickly the team can obtain meaningful feedback.

Velocity, the amount of work completed per sprint, is useful to the team for planning and harmful when used externally as a performance measure. Teams measured on velocity inflate estimates, and the number becomes meaningless while appearing to improve. It is also not comparable between teams, since estimation scales are relative and locally defined, which makes cross-team velocity comparison one of the more reliably counterproductive management practices.

Because the structure only produces value when the surrounding organization respects the commitment and acts on the review, its effectiveness is largely determined outside the team. In practice the cadence is established within product development, the review is most valuable when informed by evidence from user research rather than internal opinion, and organizations coordinating several teams usually align cadences across a product department so that dependencies can be planned rather than discovered.