Short answer
A sprint is a fixed working period, commonly one or two weeks, in which a development team commits to a defined set of work and ends with something demonstrable. The length is fixed and the scope flexes: when work runs long, items move to the next sprint rather than the sprint being extended.
Also called: Sprint cycle, Iteration
The rhythm exists to make drift visible early. A working demonstration every week or two turns an abstract percentage-complete figure into something a client can click, and a misunderstanding caught in a fortnight costs a fortnight rather than a quarter. It also creates an obligation on the client side, because sprints depend on someone being available to review and decide between them.
Sprint theatre is the failure to watch for. Stand-ups, planning sessions and retrospectives with no working software at the end are ceremony without the feedback loop that justifies them, and a two-week block of work relabelled as a sprint changes nothing about how a project runs. Velocity is a planning aid for one team, and it stops meaning anything the moment it is used as a productivity score to compare teams against each other.
Common questions
How much client time does a sprint-based project need?
Enough to review a demonstration and answer questions between sprints, which usually means a couple of hours per cycle from someone empowered to decide. The cost of being unavailable is less about idle developers than about decisions made by assumption, which surface later as rework nobody budgeted for.
Where this comes up in our work
Related terms
Product Roadmap
A product roadmap is a sequenced plan of what a product will do next and why, grouped by outcome rather than by feature list.
Scope Creep
Scope creep is the gradual expansion of a project’s requirements after the scope is agreed, usually through small additions that each seem too minor to renegotiate.
Staging Environment
A staging environment is a private copy of a live system, running the same code and configuration, used to test changes before they reach customers.
Technical Debt
Technical debt is the future cost of a shortcut taken now: code that works but is structured for speed rather than for change.
Reading definitions because you are scoping a project? Skip ahead and just ask.