What Is a Sprint in Agile?
A sprint is a short, fixed period of time — usually one, two, or four weeks — during which a Scrum team commits to completing a specific, agreed set of work. At the start of a sprint, the team plans what they'll build. During the sprint, they build it, checking in briefly every day. At the end, they review what got finished and reflect on how the sprint went, before starting the next one. Sprints are the basic rhythm that Scrum, one of the most popular ways of running Agile teams, is built around.
Quick facts
- A sprint typically lasts one, two, or four weeks — two weeks is the most common length for software teams.
- A sprint always has a fixed length, agreed in advance, and doesn't get extended partway through, even if the team is behind.
- Each sprint starts with sprint planning and ends with a sprint review and a sprint retrospective.
- The goal of a sprint is captured in a short sprint goal — a simple statement of what the team is trying to achieve during that period.
- Sprints are a core part of what a product owner does, since the product owner decides what goes into each one.
What happens during a sprint
| Stage | What happens |
|---|---|
| Sprint planning | The team looks at the top of the backlog and agrees what they can realistically finish during this sprint |
| The sprint itself | The team works through the agreed tasks, meeting briefly every day (a daily stand-up) to share progress and flag blockers |
| Sprint review | The team shows what they finished, often to stakeholders, and gets feedback |
| Sprint retrospective | The team reflects privately on how the sprint went, and agrees on one or two things to improve next time |
Why sprints are a fixed length
The fixed length is intentional, and it's one of the most important things to understand about how Scrum works. Rather than extending a sprint because the team is behind, an unfinished item simply goes back into the backlog to be picked up in a future sprint. This forces the team to get better at estimating and scoping work realistically over time, and it keeps the rhythm of planning, review, and reflection happening on a predictable schedule that stakeholders can rely on — instead of sprints stretching indefinitely whenever things run behind.
How long should a sprint actually be?
Two weeks is the most common length, because it strikes a balance: long enough to get a meaningful chunk of work done, short enough that the team gets frequent chances to re-plan and adjust based on new information. One-week sprints suit teams that need to move especially fast or are still learning to estimate well, since mistakes get caught and corrected quickly. Four-week sprints suit teams whose work naturally takes longer to complete in meaningful pieces, though longer sprints mean less frequent opportunities to change direction if priorities shift.
Sprint vs related Agile terms
- A sprint is different from a release, which is when finished work actually ships to customers — a release can happen every sprint, or only after several sprints' worth of work has built up.
- A sprint is different from a PI (Program Increment) in SAFe, which is a larger planning period, usually made up of several sprints, used to coordinate multiple teams at once.
- A sprint's planned work is drawn from the product backlog, the full running list of everything the team might build.
Common mistakes teams make with sprints
- Changing the sprint length frequently. Constantly switching between one-week and two-week sprints makes it hard for a team to build a reliable sense of how much work they can actually finish in a sprint.
- Adding new work mid-sprint. Interrupting an in-progress sprint with urgent new requests undermines the whole point of committing to a fixed, protected block of work — occasional true emergencies are unavoidable, but frequent mid-sprint additions are a sign of a planning problem.
- Treating an unfinished sprint as a failure rather than useful data. Not finishing everything planned is common, especially for newer teams — the useful response is adjusting future planning, not treating it as something to hide or punish.
- Skipping the retrospective when the team is busy. The retrospective is often the first meeting to get cut under time pressure, but it's also the main mechanism a team has for actually getting better at estimating and working together over time.
FAQ
Can a sprint be extended if the team doesn't finish? No, not in standard Scrum practice — the sprint length stays fixed, and unfinished work simply moves back into the backlog for a future sprint. Extending sprints regularly defeats the purpose of having a fixed, predictable rhythm.
Who decides how long a sprint should be? Usually the team, together with the Scrum Master and product owner, decides on a sprint length when they start working together, and then keeps it consistent across sprints so the team can build a reliable sense of its own capacity.
What's the difference between a sprint and an iteration? In most contexts, these terms mean the same thing — "iteration" is an older, more general Agile term, while "sprint" is the specific term used within Scrum. Some non-Scrum Agile approaches use "iteration" instead of "sprint" for the same basic concept.
Does every Agile team use sprints? No — sprints are specific to Scrum. Kanban, another popular Agile approach, doesn't use fixed sprints at all, instead managing work as a continuous flow. See Scrum vs Kanban for the full comparison.