Sprint

What it means

A sprint is a short fixed period, usually one to four weeks, ending with a verifiable piece of the product. It is not merely a stretch of time but a commitment to a result.

Its scope does not change mid-sprint. A new requirement goes into the next one, or the team never reaches a state where anything is genuinely finished.

A sprint is not a milestone. A milestone is a point in the plan, reached once, confirming that something has happened. A sprint is a recurring rhythm of equal length in which work is planned, finished and shown over and over. A project may have several milestones, but several sprints lead to each of them.

How it works in practice

It opens with an agreed goal and a selection of tasks and closes by showing the result to whoever ordered it. That meeting is what prevents three months of building something nobody wanted.

Sprints work only with automation: without CI/CD and tests the time goes on manual deployment and firefighting instead of finishing the agreed scope.

On bespoke work such as a custom CRM, the contract itself can be built around sprints: the company pays for each completed sprint and can stop the project after any of them. For the accounts that means partial invoices with clear content, and an easier judgement of which part of the project is already a finished asset.

What to watch out for

If unfinished tasks roll from sprint to sprint, the problem is estimates or interruptions, not people. Pushing more work into the same time only builds technical debt.

A sprint depends on the client being available. If questions from the team get an answer a week later, the team either waits or guesses, and both cost money. Introducing Scrum without the client side reserving a named person’s time therefore produces sprints that are short only on paper.