Sprint
A fixed-length unit of work (usually 1 to 2 weeks) at the end of which a shippable increment is delivered and reviewed.
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.
When this matters in a software project. Any time you are buying ongoing, iterative delivery and want to see working software at a steady cadence rather than one big reveal at the end.
What founders usually get wrong. They treat sprints as a way to hit a fixed external launch date, which is exactly backwards: the cadence fixes the time-box and flexes the scope. They also drop the demo and the retro, so they get planning meetings and ship nothing a stakeholder can click on.
How Wavect handles it. We keep the demo and the retro, and a working increment someone outside the team can use is the bar at the end of every sprint. For genuinely date-driven, fixed-scope work we plan against explicit milestones instead, as covered in the QA checklist before launch.