Sprint

Sprint is a Scrum-specific term that has leaked into general usage to mean any short, time-boxed unit of work. The original definition requires three things: a fixed length, a planning session at the start, and a review at the end. Most teams keep the first two and drop the third, which is why a lot of teams call their cadence “sprints” but produce no demonstrable increment. A sprint without a demo is just a deadline; a sprint without a retro is a treadmill.

The duration matters. One-week sprints force tight scope and surface delivery problems fast. Two-week sprints give more room for substantial work but absorb more drift. Three-week sprints almost always become two badly-planned ones.

Worked example of the silent failure: a team runs two-week “sprints” for six months, hits every planning meeting, and ships nothing a stakeholder can click on. The board keeps slipping because work is sized by hope, not by what fits, and there is no review forcing the team to confront a working increment. The fix is brutal and simple: at the end of every sprint, someone outside the team has to be able to use what was built. If they cannot, the cadence is theatre, and shrinking to one-week sprints usually exposes why within a fortnight.

The honest trade-off and the most common founder mistake: treating sprints as a way to hit a fixed external deadline. The cadence is built around fixing the time-box and flexing the scope, which is the opposite of a hard launch date with fixed scope. For genuinely date-driven, fixed-scope work you want a fixed-price plan with explicit SDLC milestones, not a sprint board. Sprints fit ongoing agile delivery and iterative work toward an MVP; they fit research and design work poorly, where a time-boxed exploration with a written summary beats a forced demo. They also depend on CI/CD being healthy, because a sprint that cannot ship at its end is not a sprint.