In short
A sprint is a fixed-length iteration, typically one or two weeks, in which a development team plans a set of work it commits to completing, builds it, demonstrates the result at a review, and holds a retrospective to improve how it works; it comes from the Scrum framework and is the most widely used unit of agile delivery. Sprints give a rhythm for planning, feedback and adjustment without long-range promises. They fail when the commitment is padded or unrealistic, when work is not finished within the sprint, or when the ceremonies become rituals. Small teams often prefer a lighter continuous flow.
The definition
Scrum, the most widely used agile framework, organises work into sprints: fixed periods of one to four weeks, most often two, at the end of which the team delivers a usable increment of the product. The length is fixed so the team learns what it can actually do in that time, and the work is chosen at the start so the sprint has a defined scope and a goal.
The idea is to replace long plans that turn out wrong with short cycles that are checked: commit to two weeks, see what happened, adjust. It is the unit that makes agile delivery concrete.
The events
Sprint planning. At the start, the team and the product owner choose items from the prioritised backlog that fit the sprint's capacity, break them into tasks, and agree a sprint goal: the one outcome the sprint exists to achieve. Planning a two-week sprint takes a couple of hours.
The daily stand-up. Fifteen minutes, every day, in which each person says what they did, what they will do, and what is blocking them. It is for coordination, not reporting to a manager, and it goes wrong when it becomes the latter.
The sprint review. At the end, the team demonstrates the working increment to stakeholders, who give feedback that shapes the next sprint's priorities. The demonstration is of software that works, not of slides.
The retrospective. The team alone discusses how the sprint went, what to keep and what to change in how they work, and agrees one or two concrete improvements. This is the mechanism by which the process gets better, and the event most often skipped.
Backlog refinement, between sprints, where upcoming items are clarified and estimated so planning is quick.
What makes it work
A realistic commitment, based on what the team has actually completed in previous sprints rather than on what would be nice. A single sprint goal that gives the work coherence. Items small enough to finish within the sprint, with a shared definition of done that includes testing and review. Protection from mid-sprint additions, so the commitment means something. And honest reviews and retrospectives, where the demonstration shows real state and the retrospective produces changes that are made.
The failure modes
Sprints as mini-waterfalls. Design in week one, build in week two, test never; nothing is done at the end.
Chronic overcommitment. Every sprint plans more than the last one delivered, every sprint ends with carry-over, and the commitment stops meaning anything.
Scope injected mid-sprint. Stakeholders add urgent items; the goal is abandoned; the team learns that planning is theatre.
Ceremonies without content. Stand-ups that are status reports, reviews with no working software, retrospectives that produce no change.
Velocity as a target. Story points are an estimation aid; when they become a performance metric, estimates inflate and the number stops informing anything.
Sprints for work that is not sprint-shaped. Support, operations and research do not arrive in two-week batches and are better handled as flow.
The alternatives
Kanban drops fixed iterations for a continuous flow: work is pulled from a prioritised queue as capacity frees, with limits on work in progress, and planning and review happen on demand or on a cadence separate from delivery. It suits teams with unpredictable incoming work and teams mature enough not to need the sprint's forcing function.
Continuous delivery without sprints, where small changes ship as they are ready and priorities are reviewed weekly, is common in small product teams and is closer to how many ship-small-ship-often studios work.
Shape Up, from Basecamp, uses six-week cycles with fixed time and variable scope, and a cooldown between them; it suits teams that find two weeks too short to finish anything meaningful.
Agencies and small teams
A two-week sprint gives a client a predictable rhythm: a planning conversation, a demonstration, a chance to redirect, every fortnight. That is valuable, and it is the reason many agencies bill and report by sprint. The adaptations that work: the client as product owner in planning and review, with real decisions; a goal per sprint the client can recognise; the demonstration on a staging environment; and a lighter retrospective that still happens. A team of two or three usually drops the daily stand-up for a shared board and a brief check-in, and that is fine; the rhythm of commit, show, adjust is the part worth keeping.
Sprints are a tool for making promises small and checking them often. Teams that keep them honest get predictability; teams that let them become ritual get meetings. If you would like to see how a fortnightly sprint with reviews on a live staging site works in practice, book a call; it is how we run most projects.
Common questions
How long is a sprint?
Usually two weeks; one week and three or four weeks are also used. The length is fixed for a team so it learns what it can deliver in that time and can plan realistically. Shorter sprints give faster feedback and more planning overhead; longer ones allow bigger items and risk becoming mini-projects.
What is the difference between a sprint and an iteration?
A sprint is Scrum's name for an iteration: a fixed-length cycle with planning at the start, a review and retrospective at the end, and a committed set of work in between. Other frameworks use the word iteration for similar cycles with different rules. In everyday use the terms are interchangeable.
What is a sprint goal?
The single outcome a sprint exists to achieve, agreed at planning, such as 'customers can complete checkout with a saved card'. It gives the chosen work coherence, guides decisions when something has to be cut mid-sprint, and is what the review demonstrates. A sprint without a goal is a list of tasks, not a commitment.
What happens if work is not finished in a sprint?
Unfinished items return to the backlog and are reprioritised for the next sprint; they are not automatically carried over. The retrospective examines why: overcommitment, items too large, mid-sprint additions or blockers. Chronic carry-over means the team is planning more than its measured capacity and should commit to less.
Do small teams need sprints?
Not necessarily. Teams of two or three often prefer a continuous flow with a shared board, work-in-progress limits and a weekly priorities check, which keeps the commit-show-adjust rhythm without the ceremonies. Sprints are most valuable when a client or stakeholder benefits from a predictable fortnightly cycle of planning, demonstration and redirection.
