Sprint

Sprints come from Scrum, the best-known agile framework, whose official guide caps a sprint at one month. The length is fixed in advance and does not stretch: if work is not finished, it goes back into the backlog rather than extending the sprint.

A sprint is not the same as a deadline for the whole project, and it is not a rush to work overtime. The word suggests speed, but the point is rhythm. Every cycle produces a checkpoint where the client sees progress and can change direction.

How it works

A sprint opens with planning. The team and the product owner, the person who sets priorities, pick the top items from the backlog, usually user stories, and agree a sprint goal: one sentence describing what the sprint should achieve, such as "patients can book a cleaning appointment online". The team only takes on as much as it believes it can finish, based on how much it completed in previous sprints.

During the sprint the team meets briefly each day, capped at 15 minutes in Scrum, to say what moved, what is next and what is blocked. New requests from outside are not added mid-sprint; they wait for the next planning session. If the sprint goal itself becomes obsolete, the product owner can cancel the sprint and the team plans a new one. This protection is what lets the team finish things instead of switching constantly.

The sprint ends with two meetings. In the review, the team demonstrates the finished work to the client and stakeholders, who give feedback that reshapes the backlog. In the retrospective, the team discusses its own process: what slowed it down and one or two things to try differently next time. Then the next sprint starts immediately.

Example

A travel agency is building a new booking site in two-week sprints. Sprint three has the goal "customers can search trips by destination and month". The team takes five stories: the search box, the month filter, the results list, an empty-results message and storing departure dates in the CMS. By day ten four are done. The empty-results message is unfinished, so it returns to the backlog rather than delaying the review.

At the review the agency's owner tries the search on her phone and notices customers will want to filter by budget too. That becomes a new story, ranked for sprint four. Nothing already promised for sprint three changes, and the owner leaves the meeting having used the real feature rather than looking at a slide.

Why it matters for your business

Sprints give you regular, predictable moments to see what your money has bought and to correct course, which limits how much can go wrong before anyone notices. After a few sprints the team's pace becomes measurable, so forecasts of the remaining work get more reliable. The cost is your time: someone on your side needs to attend reviews and make priority calls. For a small fixed-scope site lasting a few weeks, formal sprints add ceremony without much benefit. You can check whether sprints are working by asking at each review to use the new features yourself, not just watch a demonstration.

Common mistakes

• Extending a sprint by a few days to squeeze in unfinished work, which removes the predictable rhythm sprints exist for.
• Adding new requests in the middle of a sprint, so the team never finishes what it planned.
• Running reviews as slide presentations rather than showing working software that stakeholders can try.
• Skipping the retrospective, so the same problems repeat every cycle.

Questions people ask

How long is a sprint?

Most teams use one or two weeks. The Scrum Guide allows up to one month. Shorter sprints give more frequent feedback but more meeting overhead; longer ones suit work with longer build steps. Whatever the length, keep it the same from sprint to sprint so pace can be measured.

What happens if work is not finished by the end of a sprint?

It goes back to the backlog and is reprioritised for a future sprint. The sprint is not extended. The team then looks at why it overcommitted, for example because a story was larger than estimated, and plans the next sprint with that in mind.

Do I need to attend every sprint meeting as a client?

No. Daily check-ins are for the team. You should attend the sprint review, and ideally be available for planning or at least approve the priorities beforehand. Those are the moments where your decisions shape what gets built next.