Agile guide · Agile practices
What Is a Sprint in Agile? Length, Events and Examples
A sprint in Agile is a short, fixed period, one month or less and most often two weeks, in which a team turns a set of backlog items into a usable result. Sprints give Agile teams a steady rhythm of planning, building, reviewing and improving. This guide explains how sprints work, how long they should be, what happens inside one, and what a real two-week sprint looks like day by day.
Key takeaways
- A sprint is a fixed time-box of one month or less with a single Sprint Goal; two weeks is the most common length.
- Every sprint contains Sprint Planning, Daily Scrums, a Sprint Review and a Sprint Retrospective, and ends with a usable Increment.
- The Sprint Goal is the commitment. Scope can be renegotiated, but changes that endanger the goal are avoided.
- Sprints are never extended. Unfinished work goes back to the Product Backlog and the next sprint starts straight away.
- Only the Product Owner can cancel a sprint, and only if the Sprint Goal becomes obsolete.
- Most sprint problems come from overcommitting, vague goals and starting too much work at once.
What is a sprint in Agile?
A sprint is a fixed-length period of one month or less in which an Agile team works towards a single Sprint Goal and produces at least one usable Increment of the product. Sprints run back to back with no gap, and every planning, coordination, review and improvement activity for the product happens inside them.
The term comes from Scrum, the most widely used Agile framework. The Scrum Guide (2020 edition, still the current official version) describes sprints as the heartbeat of Scrum, where ideas are turned into value. Other Agile methods use the word iteration for the same idea, and many teams that do not follow Scrum strictly still say "sprint".
Whatever the name, a sprint has five defining features:
- Fixed length. The length is set in advance and stays the same from sprint to sprint, so the team learns its pace.
- One goal. Each sprint has a Sprint Goal: a single objective that explains why the sprint is worth doing.
- A usable result. By the end the team has an Increment that meets the Definition of Done, even if it is not released yet.
- Back to back. A new sprint starts immediately after the previous one ends.
- Everything inside. Planning, daily coordination, refinement, review and retrospective all happen within the sprint, not before or after it.
Short, fixed cycles are what make Agile empirical: every few weeks the team and its stakeholders look at real, working output and decide what to do next.
Sprint vs iteration vs Scrum
These terms are often mixed up. The table shows how they relate.
| Term | What it is | Where it is used |
|---|---|---|
| Sprint | A fixed time-box of one month or less that produces a usable Increment | Scrum, and loosely across most Agile teams |
| Iteration | The general name for a repeated, time-boxed development cycle | XP, SAFe, DSDM/AgilePM and general Agile writing |
| Scrum | The framework that defines sprints, roles, events and artefacts | Teams following the Scrum Guide |
| Release | Delivering an Increment to users; can happen several times per sprint or after several sprints | All delivery approaches |
| Program Increment (PI) | A longer planning interval, typically several iterations, used to align many teams | SAFe (Scaled Agile Framework) |
In short, a sprint is one kind of iteration, and Scrum is the framework that gives the sprint its rules. The idea behind both is iterative and incremental development: build the product in small slices and improve it each cycle.
How long is a sprint?
The Scrum Guide sets only one rule: a sprint lasts one month or less. Within that limit, the team chooses. In practice most teams run sprints of one to four weeks, and two weeks is by far the most common choice because it balances fast feedback against the overhead of planning and reviewing.
| Length | Works well for | Watch out for |
|---|---|---|
| 1 week | Fast-moving products, early-stage start-ups, teams that need very quick feedback | Events take a larger share of the time; hard to finish larger items |
| 2 weeks | Most teams; a good default when you are starting out | Can still hide a mini-waterfall if items are too big |
| 3 weeks | Teams with longer test cycles or regulated sign-off steps | Less common, so harder to align with other teams |
| 4 weeks / one month | Complex work that needs longer to show results; stable environments | Slower feedback, more risk of drifting from the goal, bigger planning sessions |
How to choose a sprint length
Pick the shortest length in which the team can deliver something meaningful and Done. Then consider:
- How quickly things change. The more volatile the market or requirements, the shorter the sprint.
- How long feedback can wait. If stakeholders need to see progress every week, a four-week sprint is too long.
- Item size. If most backlog items take more than a few days, split them before you lengthen the sprint.
- Release and test constraints. Integration, compliance checks or hardware lead times can make very short sprints impractical.
- Alignment. Teams working on the same product usually share a sprint length and start date.
Changing sprint length
Keep the length stable for at least several sprints so that your velocity and forecasts mean something. Change it deliberately in a retrospective, not mid-sprint, and never stretch a single sprint because work is unfinished. For the Scrum-specific rules, see our guide to the Scrum sprint cycle.
The building blocks of a sprint
Three things give a sprint its shape: a goal, a plan and a result.
Sprint Goal
The Sprint Goal is the single objective for the sprint. It is created during Sprint Planning and is the commitment the Developers make. A good Sprint Goal describes an outcome, not a list of tickets, which leaves the team room to adjust the detailed work as it learns.
- Weak: "Complete tickets 412, 415, 419 and 420."
- Better: "Let returning customers check out in one step so we can test whether it reduces abandoned baskets."
- Non-software example: "Launch the spring campaign landing page and first two emails so the sales team can start outreach on Monday."
Sprint Backlog
The Sprint Backlog is made up of the Sprint Goal, the Product Backlog items selected for the sprint and the Developers' plan for delivering them. It belongs to the Developers, who update it throughout the sprint so that everyone can see the work remaining.
Increment and Definition of Done
An Increment is a step towards the product goal that is usable and meets the Definition of Done. Work that does not meet the Definition of Done is not part of the Increment, however close it is. Several Increments can be created in one sprint, and they can be released at any time; the Sprint Review is not a release gate.
The events inside a sprint
The sprint is a container for four other events. The time-boxes below are the maximums the Scrum Guide gives for a one-month sprint; for shorter sprints the events are usually shorter.
| Event | Purpose | Who takes part | Maximum time-box (one-month sprint) |
|---|---|---|---|
| Sprint Planning | Agree why the sprint is valuable (Sprint Goal), what can be done and how | Whole Scrum Team | 8 hours |
| Daily Scrum | Inspect progress towards the Sprint Goal and adapt the plan for the next day | Developers (others may attend) | 15 minutes, every day |
| Sprint Review | Show the result to stakeholders and adapt the Product Backlog | Scrum Team and key stakeholders | 4 hours |
| Sprint Retrospective | Improve how the team works: people, process, tools, Definition of Done | Scrum Team | 3 hours |
Sprint Planning opens the sprint. The Product Owner explains which objectives matter most, the Developers select items they believe they can finish, and together the team crafts the Sprint Goal. The Developers then plan how to do the work, often by breaking items into tasks of a day or less.
The Daily Scrum is a 15-minute check for the Developers. It is not a status report to a manager. The question that matters is: are we on track for the Sprint Goal, and what do we change today if not?
The Sprint Review is a working session, not a slide show. The team demonstrates what is Done, stakeholders give feedback, and the group discusses what to do next, which updates the Product Backlog.
The Sprint Retrospective closes the sprint. The team picks a small number of concrete improvements, and the most important can be added to the next Sprint Backlog.
Backlog refinement is not an event but an ongoing activity during the sprint. The team clarifies, splits and sizes upcoming items so that the next Sprint Planning goes quickly.
For agendas and facilitation tips for each meeting, see our guide to Scrum ceremonies.
Who does what in a sprint
A Scrum Team has three accountabilities. All three are needed for a sprint to work.
| Role | Main responsibilities during a sprint |
|---|---|
| Product Owner | Orders the Product Backlog, proposes how the sprint can add value, answers questions about items, works with stakeholders on what comes next, and is the only person who can cancel a sprint |
| Developers | Select the work, create the plan, build and test the Increment, hold the Daily Scrum, update the Sprint Backlog and hold each other accountable |
| Scrum Master | Makes sure the events happen and stay within their time-boxes, removes impediments, coaches the team and the organisation |
| Stakeholders | Join the Sprint Review, give feedback and help decide what comes next |
Notice that nobody assigns tasks to the Developers; they organise the work themselves.
How to plan and run a sprint, step by step
This is our recommended sequence for a team running its first sprints. It follows the Scrum Guide, with practical habits added.
- Prepare the Product Backlog. Before planning, make sure the top items are ordered, clear and small enough to finish within the sprint. Refinement in the previous sprint does this.
- Check capacity. List holidays, training and other commitments so you know how much time the team really has. Our Agile capacity planning guide explains how.
- Agree the Sprint Goal. In Sprint Planning, the Product Owner proposes the objective and the team shapes it into one clear sentence.
- Select the work. The Developers pull items from the top of the backlog until they reach a realistic load, using recent velocity or throughput as a guide.
- Plan the how. Break the first few days of work into tasks and agree who starts what. You do not need to plan every task up front.
- Work in small batches. Finish items before starting new ones. When someone is blocked, others help; this is called swarming.
- Inspect daily. Use the Daily Scrum and a visible Scrum board to spot risks to the Sprint Goal early.
- Refine upcoming work. Spend some time each sprint preparing the next set of items; earlier editions of the Scrum Guide suggested this usually takes no more than 10% of the team's capacity, and many teams still use that as a rule of thumb.
- Review with stakeholders. Show what is Done, collect feedback and update the Product Backlog.
- Improve. Hold the retrospective, choose one or two actions and carry them into the next sprint, which starts straight away.
A ready-made sprint planning template gives you a place for the Sprint Goal, capacity, selected items and tasks.
Example: a two-week sprint, day by day
Here is how a typical two-week sprint might look for a product team of six working Monday to Friday. Times are illustrative; adjust them to your own calendar.
| Day | What happens |
|---|---|
| Day 1 (Mon) | Sprint Planning (about 2–4 hours). Sprint Goal agreed; items selected; first tasks planned |
| Days 2–4 | Daily Scrum each morning. Developers build and test the first items, finishing them one at a time |
| Day 5 (Fri) | Mid-sprint check at the Daily Scrum: is the goal still achievable? Scope renegotiated with the Product Owner if needed |
| Days 6–7 | Work continues. A refinement session prepares items for the next sprint |
| Days 8–9 | Remaining items finished and integrated. No new large items started |
| Day 10 (Fri) | Sprint Review (about 1–2 hours) with stakeholders, then Sprint Retrospective (about 1–1.5 hours) |
| Next Monday | The next sprint begins with Sprint Planning |
Example Sprint Goals
- Software product: "New users can sign up with a work email and invite one colleague, so we can start the onboarding beta."
- Marketing team: "Publish the webinar landing page and registration flow so we can open sign-ups for the June event."
- HR team: "Pilot the new onboarding checklist with the two starters joining this month."
- Internal IT: "Move the finance team to the new laptop build with no loss of access to shared drives."
Can you change, extend or cancel a sprint?
The Scrum Guide gives clear rules for a sprint in progress:
- No changes that endanger the Sprint Goal. New urgent work can be discussed, but the team protects the goal.
- Quality does not decrease. The Definition of Done is not relaxed to hit a date.
- Scope can be clarified and renegotiated with the Product Owner as the team learns more. Items can be swapped or dropped as long as the goal still holds.
- The Product Backlog is refined as needed.
Extending a sprint is not allowed. The time-box is fixed. Work that is not Done returns to the Product Backlog, where the Product Owner re-orders it; it is not automatically carried into the next sprint, and partial work does not count towards velocity.
Cancelling a sprint is possible but rare. Only the Product Owner can do it, and only if the Sprint Goal becomes obsolete, for example because the company changes direction or the market shifts. Any Done work is reviewed, and incomplete items go back to the Product Backlog.
If stakeholders keep pushing new work into running sprints, treat it as a form of scope creep: route requests through the Product Owner and the Product Backlog instead.
How to track progress during a sprint
You do not need complex reporting to manage a sprint, but you do need to see whether the goal is on track.
- Scrum or Kanban board. Columns such as To do, In progress, Review and Done show work at a glance and make bottlenecks visible.
- Sprint burndown chart. Plots the work remaining each day against an ideal line. A flat line for several days is an early warning.
- Sprint Goal check. At each Daily Scrum, ask whether the goal is still achievable; this matters more than any chart.
- Velocity or throughput (after the sprint). The amount of work finished per sprint, used to plan future sprints. See Agile velocity charts.
- Sprint Goal success rate. Over several sprints, how often the team met its goal is a useful measure of predictability.
Whatever you track, use it to help the team adapt, not to compare teams or individuals.
Benefits of working in sprints
- Fast feedback. Stakeholders see working results every few weeks rather than at the end of the project.
- Focus. A single goal and a short horizon reduce multitasking and context switching.
- Lower risk. Problems surface within one sprint, when they are cheaper to fix.
- Predictability. A steady cadence makes it easier to forecast and to plan releases.
- Built-in improvement. The retrospective gives the team a regular, protected time to improve how it works.
- Transparency. Goals, backlogs and boards make progress visible to everyone.
Common sprint mistakes and how to fix them
| Mistake | Why it hurts | Fix |
|---|---|---|
| Overcommitting | Work spills over, morale drops and forecasts become meaningless | Plan to recent velocity and real capacity; commit to the goal, not to every item |
| No real Sprint Goal | The sprint becomes a to-do list with no reason to adapt | Write one outcome-based sentence in Sprint Planning |
| Mini-waterfall inside the sprint | Analysis, build and test happen in sequence, so nothing is Done until the last day | Split items so each can be built and tested in a few days |
| Too many items in progress | Everything is 90% done at the end | Limit work in progress and finish before starting |
| Extending the sprint | Breaks the cadence and hides the real problem | Return unfinished work to the backlog and discuss why in the retrospective |
| Skipping the retrospective | The same problems repeat sprint after sprint | Keep it short if you must, but always hold it and act on one improvement |
| Changing sprint length often | Velocity and forecasts lose their meaning | Keep the length stable and change it only deliberately |
| Using the Daily Scrum as a status meeting | Developers report to a manager instead of planning together | Focus on the Sprint Goal and the plan for the next 24 hours |
Do all Agile teams use sprints?
No. Sprints belong to Scrum and to iteration-based methods such as XP and SAFe. Other approaches work differently:
- Kanban uses continuous flow with work-in-progress limits instead of fixed sprints; planning and releases happen when needed. Compare them in Kanban vs Scrum.
- Scrumban mixes the two, often keeping a planning cadence while managing work as a flow.
- Design sprints are a different idea: a structured, roughly five-day workshop (popularised by Google Ventures) to explore and test a product concept. It shares the name but not the Scrum rules.
To see how these approaches compare, read types of Agile methodologies.
Sprint templates and tools
You can run sprints with sticky notes and a whiteboard, but templates and software make the work easier to share, especially for remote teams.
- Sprint planning template: Sprint Goal, capacity, selected items, estimates and tasks.
- Sprint retrospective template: what went well, what to improve and action items.
- Product backlog template: an ordered list of items ready for future sprints.
- User story template: consistent stories with acceptance criteria and estimates.
- Agile project plan template: releases, sprints and milestones in one view.
Most project management tools now support sprints. Jira is built around Scrum and Kanban boards for software teams, while Wrike, our top-rated tool overall, suits teams that run sprints alongside other kinds of work across departments.
Free templates for this topic
Frequently asked questions
What is a sprint in simple terms?
A sprint is a short, fixed block of time, usually two weeks, in which a team agrees one goal, does the work to reach it, shows the result and then improves how it works before the next sprint begins.
How long is a sprint in Agile?
In Scrum a sprint lasts one month or less. Most teams use one to four weeks, and two weeks is the most common length. The length is kept the same from sprint to sprint.
Why are most sprints two weeks long?
Two weeks is long enough to finish meaningful work and short enough to get frequent feedback. It also keeps planning and review overhead reasonable. It is a convention, not a rule in the Scrum Guide.
What is the difference between a sprint and an iteration?
A sprint is Scrum's name for an iteration: a repeated, time-boxed development cycle. Other methods such as XP and SAFe use the word iteration for the same idea.
What is the difference between Scrum and a sprint?
Scrum is the framework, with its roles, events and artefacts. A sprint is one of Scrum's events: the fixed time-box that contains all the other events and the work.
What happens at the end of a sprint?
The team holds a Sprint Review to inspect the Increment with stakeholders and update the Product Backlog, then a Sprint Retrospective to improve how it works. The next sprint starts immediately.
What happens to unfinished work at the end of a sprint?
It returns to the Product Backlog, where the Product Owner re-orders it. It does not count as Done or towards velocity, and it is not automatically carried into the next sprint.
Can you extend a sprint?
No. The sprint is time-boxed. If work is not finished, it goes back to the Product Backlog and the next sprint starts on schedule. Discuss the cause in the retrospective.
Who can cancel a sprint?
Only the Product Owner, and only if the Sprint Goal becomes obsolete. Cancellation is rare because sprints are short and the team can usually adapt the plan instead.
Is there a break between sprints?
No. According to the Scrum Guide, a new sprint starts immediately after the previous one ends. Some teams schedule innovation or hack time, but in Scrum that happens within a sprint.
What is sprint zero?
An informal term for a preparation period before the first sprint, used to set up tools, environments and an initial backlog. The Scrum Guide does not define it, and many coaches recommend keeping it very short or delivering something usable even in the first sprint.
How many user stories should be in a sprint?
There is no fixed number. Several small stories, each finishable in a few days, usually work better than a few large ones. Use recent velocity or throughput as a guide.
Who decides what goes into a sprint?
The Product Owner orders the Product Backlog and proposes the objective. The Developers decide how much they can take on and select the items. The whole Scrum Team agrees the Sprint Goal.
Does Kanban use sprints?
No. Kanban manages work as a continuous flow with work-in-progress limits rather than fixed time-boxes, although some Kanban teams hold regular planning or review meetings on a cadence.