The Agile Sprint Cycle: Every Event, Its Timebox, and What It Produces
The Agile Sprint Cycle is a repeating timeboxed period of a month or less containing four events: sprint planning, a daily replan, a review of the product and a retrospective on the work.
Before you start
Is this your framework?
This page covers the loop itself: what happens on which day of a sprint, how long each event gets, and what it has to produce before the sprint moves on.
It is about the mechanics of the cycle, not about how a team is organized around it. If the question is who is accountable for what, that is a different page, and the table below says which.
| If your real problem is… | You probably want |
|---|---|
| We need the accountabilities, artifacts and rules, not the daily rhythm | Scrum Framework — who is answerable for what, and what the framework actually specifies Compare the Sprint Cycle and Scrum |
| Work arrives continuously and a fixed cycle fights against it | Kanban — flow and work-in-progress limits, with no iteration boundary Compare the Sprint Cycle and Kanban |
| We cannot agree what goes into the sprint in the first place | RICE — ranking a backlog, which the cycle assumes is already done |
| The backlog is flat and nobody can see the product in it | User Story Mapping — structure and release slices upstream of any sprint |
| We need dates and dependencies across months, for people outside the team | Gantt Chart — a schedule view, which a sprint cycle deliberately does not give |
| The retrospectives surface the same things and nothing changes | Kaizen — making improvement actually happen between the events |
| We run sprints and are not sure what each event is for or how long it should take | The Agile Sprint Cycle — you are in the right place |
What Is It?
A sprint is a fixed period, a month or less, inside which a team plans, works, and then stops to look at two things: what it built, and how it built it. When it ends the next one starts immediately. That is the cycle.
The fixed length is the working part. Because the period cannot be extended, taking on too much shows up as unfinished work rather than as a slipped date, and it shows up within weeks rather than at the end of a project. The cadence converts an estimation problem into a visible, repeated, cheap piece of feedback.
Four events punctuate it. Planning decides why this sprint is worth running and what will be attempted. A short daily replan keeps the team pointed at that. A review shows the actual product to the people who care about it. A retrospective looks at how the work went. Everything else is up to the team.
The events are commonly described as phases, which is misleading. Development work does not happen in a stage between the meetings; it runs the whole way through, and refinement of what comes next runs alongside it. The events are checkpoints, not segments of a pipeline.
The most common mistake is treating the timeboxes as targets to fill. They are ceilings. A sprint planning session that reliably takes its full eight hours is usually one where the backlog was not ready, and the fix is upstream rather than in the room.
Quick Reference
The cycle
Every event, its timebox and its output
Timeboxes below are the published maximums for a one-month sprint. For shorter sprints they are usually shortened in proportion, with one exception.
| Event | When, and how long | What it has to produce, and how it fails |
|---|---|---|
| Sprint Planning | Day one. Up to 8 hours for a month, so roughly 4 for a fortnight. | A Sprint Goal in one sentence, the items selected, and a plan for the first days. Fails when it produces only a list of tickets, which means nobody can say why this sprint was worth running. |
| Daily Scrum | Every day, same time. 15 minutes regardless of sprint length. | A revised plan for the day against the Sprint Goal. Fails when it becomes a status report to a manager, which is what a fixed script produces. |
| Sprint Review | Near the end. Up to 4 hours for a month. | Feedback on the actual working product from people outside the team, and an updated backlog. Fails as a slide presentation with nothing running. |
| Sprint Retrospective | Last, after the review. Up to 3 hours for a month. | One improvement the team will actually attempt next sprint. Fails when findings are recorded and never actioned, which teaches the team that inspection is decorative. |
| Refinement | Continuous, not an event. Commonly capped near a tenth of capacity. | A backlog ready enough that the next planning session is short. It is the usual reason planning overruns, and it is not on the calendar. |
Review and retrospective are separate for a reason
They ask different questions of different audiences. The review is about the product and involves stakeholders; the retrospective is about the team's own working and does not. Merging them to save an hour reliably means the second conversation is the one that gets dropped, because product feedback is louder and there is always more of it.
The other pairing worth protecting is planning and refinement. If planning consistently runs long, the cause is almost never the meeting. It is that items arrived unrefined and the team is doing discovery work in a room booked for decisions. Refinement has no scheduled slot, which is exactly why it gets skipped.
Terminology
Iteration, sprint, and the IP sprint
Three terms get used for overlapping things, and which one someone uses tells you which tradition they came from.
| Term | Where it comes from | What it means, and what it adds |
|---|---|---|
| Iteration | Extreme Programming, and general agile use | Any timeboxed cycle of development. The generic term, with no further requirements attached. |
| Sprint | Scrum | An iteration plus Scrum's rules: a month or less, a Sprint Goal, fixed length, and a new one starting as the last ends. Every sprint is an iteration; not every iteration is a sprint. |
| IP iteration | SAFe | Innovation and Planning: a buffer at the end of a Program Increment for planning the next one, innovation time, and the integration work squeezed out of delivery iterations. No Scrum equivalent exists. |
The difference is usually not worth arguing about, except once
In ordinary conversation iteration and sprint are interchangeable and correcting people is not useful. The one place it matters is when somebody says they run sprints but not to a fixed length, or without a goal, or extending them to finish work. Those are iterations, which is fine, but the Scrum rules that were dropped are the ones that made the cadence informative.
The IP iteration is worth knowing about separately, because teams meet it when an organization adopts SAFe and reasonably ask why the Scrum Guide never mentions it. It does not, and will not: it belongs to a different framework and solves a coordination problem that only appears when many teams share a release cadence.
Core Features
- A fixed length: a month or less, and the same every time
- A goal per cycle: one sentence saying why this sprint is worth running
- Four events with ceilings: planning, daily, review, retrospective
- Two separate closing conversations: one about the product, one about the team
- Continuous refinement: unscheduled, and the usual reason planning overruns
- No extension: unfinished work returns to the backlog rather than stretching the cycle
Worked example
Seven in ten unfinished items were waiting on someone else
An illustrative composite. A payments team of nine at a bank in Warsaw, Poland, running two-week sprints for eighteen months. Sprints were routinely finishing with a third of the committed work incomplete, and the team had asked to move to three-week sprints.
| What was examined | What it showed |
|---|---|
| Where planning time went | Sessions ran 3h50 against a 4h ceiling, every time. Roughly two thirds of it was spent working out what items meant, not deciding what to take. Refinement had no slot and was not happening. |
| The daily | Averaged 26 minutes against a 15-minute ceiling. Each person reported to the delivery manager in turn. Nobody replanned anything; the plan was whatever had been set on day one. |
| What was actually incomplete | Across six sprints, 31 of 44 unfinished items were blocked on a dependency outside the team, not on capacity. A longer sprint would have hidden this for an extra week rather than fixing it. |
| Review and retrospective | Merged into one 90-minute session with stakeholders present. Retrospective items had been recorded for eighteen months and none had been actioned. |
| What changed | Sprint length stayed at two weeks. Refinement got 90 minutes mid-sprint. The two closing sessions were separated. The dependency was raised as an organizational problem rather than a team one. Planning fell to about 70 minutes. |
The request was to lengthen the sprint. The sprint was not the problem
Seven in ten unfinished items were waiting on another team. Extending to three weeks would have produced the same proportion incomplete, one week later, with slower feedback — and it would have removed the very signal that made the dependency visible. The pressure to lengthen a sprint is often pressure to stop seeing something.
The cheapest fix was the one nobody had asked for. Giving refinement 90 minutes cut planning from nearly four hours to about seventy minutes, because the room stopped being used for discovery. The overrunning event was not the broken one; it was the event downstream of the missing one.
When to Use
- Requirements will change as the team learns, so a long plan would be wrong
- Something usable can be produced inside a few weeks
- A team of ten or fewer can work together on one thing
- Stakeholders will look at working output regularly
- You want overcommitment to surface in weeks rather than at the end
- The team can be left alone between the fixed points
When NOT to Use
- Work arrives unpredictably and must be picked up the day it lands
- Nothing meaningful can be completed inside a month, however thin
- Requirements are genuinely stable and the sequence is known
- The team is spread across several products with no shared goal
- External dependencies control most of the work, which no cadence fixes
- Nothing found in a retrospective will ever be acted on
Terminology
How the cycle goes wrong
Most of these are the cadence working correctly and the organization treating the signal as the problem.
| Failure mode | What it looks like | What to do instead |
|---|---|---|
| Extending the sprint | The cycle stretches to fit unfinished work, so overcommitment stops being visible | Keep the length fixed. Unfinished items go back to the backlog; that is the information. |
| Planning as discovery | Sessions run to the ceiling every time because items arrive unrefined | Give refinement a slot mid-sprint. The overrunning event is rarely the broken one. |
| The daily as status | Everyone reports in turn to a manager, it overruns, and no plan changes | Drop the script. Ask what has to change today to still meet the Sprint Goal. |
| Review merged with retrospective | One session with stakeholders present, and the team conversation quietly disappears | Separate them. Different questions, different audiences, and the second one is the fragile one. |
| No sprint goal | A batch of unrelated tickets, so there is nothing to replan against daily | One sentence before the sprint starts. If it cannot be written, the sprint is not ready. |
| Velocity as a target | Estimates inflate, the number rises, delivery does not change | Use it to size the next sprint and nothing else. Never report it upward as performance. |
| Changing sprint length | Two weeks, then three, then two, so nothing can be compared across cycles | Pick one and hold it for at least six sprints before judging anything. |
Sourced
Evidence, and how to cite it
The timeboxes are maximums for a one-month sprint, not targets.
The Scrum Guide gives Sprint Planning a ceiling of eight hours for a one-month sprint, the Sprint Review four hours, and the Retrospective three, with shorter events usual for shorter sprints. The Daily Scrum is fifteen minutes whatever the sprint length. They are expressed as upper bounds because the intent is to prevent events consuming the sprint, not to fill the time. A team routinely hitting the ceiling is reporting a problem upstream of the event.
Schwaber, K. and Sutherland, J. (2020) The Scrum Guide.
Iteration is the older and broader term; sprint is Scrum's version with rules attached.
Timeboxed iterations were established in Extreme Programming and in iterative development practice before Scrum popularized the word sprint. The distinction is not pedantic in one respect: a sprint carries requirements an iteration does not, namely a fixed length of a month or less, a Sprint Goal, and immediate succession. SAFe uses iteration rather than sprint, which is why teams moving between frameworks meet both words for what looks like the same thing.
Beck, K. (1999) Extreme Programming Explained. Reading: Addison-Wesley; Schwaber and Sutherland (2020) on the Sprint.
The IP sprint is a SAFe concept and appears nowhere in Scrum.
The Innovation and Planning iteration sits at the end of a Program Increment in SAFe and provides a cadence buffer: time for planning the next increment, for innovation, and for the integration, infrastructure and compliance work that gets crowded out of delivery iterations. It exists because many teams sharing a release cadence need a synchronization point, which is a problem a single Scrum team does not have. Teams encountering it after learning Scrum reasonably wonder why the Guide is silent; it is silent because it is a different framework.
SAFe body of knowledge on the Innovation and Planning iteration; no corresponding concept exists in the Scrum Guide.
There is no good evidence about the right sprint length.
Two weeks is by far the commonest choice and the reasoning offered for it is plausible rather than demonstrated: short enough for quick feedback, long enough that event overhead is not disproportionate. No controlled comparison establishes an optimum, and the teams that choose different lengths differ in many other ways. What is defensible is narrower: a length that changes between cycles makes comparison across sprints meaningless, so consistency matters more than the number.
Assessment of the software engineering literature as of 2026; sprint length conventions are practice, not findings.
How to cite it.
Harvard: Schwaber, K. and Sutherland, J. (2020) The Scrum Guide. Available at scrumguides.org.
APA: Schwaber, K., & Sutherland, J. (2020). The Scrum Guide.
Give the year, because the 2020 revision changed the vocabulary. For iterations generally, cite Beck (1999). For the IP iteration, cite SAFe, not Scrum.
Key Strengths
- Overcommitment surfaces fast: in weeks, as unfinished work, not as a slipped date
- Regular forced inspection: two different conversations, on a fixed date
- Predictable rhythm: everyone knows when things get decided and shown
- Cheap to correct course: the most you can be wrong by is one sprint
- Widely understood: new team members arrive knowing the shape
Key Weaknesses
- Event overhead: real, and proportionally worse on short sprints
- Fights unpredictable work: a poor fit for support and operations
- Says nothing about dependencies: which cause most missed sprints
- Encourages short-horizon thinking: nothing in the cycle looks past it
- Hollow when the events are ritual: the same calendar, none of the value
Sequencing
What to run before and after
The cycle runs on a backlog it does not produce, and surfaces problems it cannot fix.
Before
Get the backlog ordered and refined enough to plan from
Planning that runs to its ceiling every time is almost always doing discovery. That work belongs to refinement, which has no slot on the calendar and so gets skipped.
During
Decide who is accountable for what, and limit what is in flight
The cycle sets the rhythm; it does not say who orders the backlog or removes impediments. Where work arrives continuously alongside sprint work, a flow limit stops the two destroying each other.
After
Act on what the retrospectives find, especially outside the team
Most missed sprints are dependencies, not capacity. Those findings have to leave the team and land with someone who can change them, or the same items recur every sprint.
Common questions
The sprint cycle: quick answers
What is the agile sprint cycle?
The repeating loop a team runs inside a fixed period, usually one to four weeks. Planning opens it, a short daily replan keeps it on course, and it closes with a review of the product and a retrospective on how the team worked. The next sprint starts immediately. The events are fixed points; what happens between them is the team's own business.
What are the phases of a sprint?
Sprint Planning on day one, development work through the middle with a Daily Scrum each day, then the Sprint Review and the Sprint Retrospective at the end. Refinement of the backlog for the next sprint happens continuously rather than as a phase. Calling these phases is slightly misleading: the work does not proceed in stages, it runs throughout.
How long should each sprint event take?
For a one-month sprint the published maximums are eight hours for Sprint Planning, fifteen minutes for the Daily Scrum, four hours for the Sprint Review and three hours for the Retrospective. For shorter sprints they are usually shorter in proportion, except the Daily Scrum, which is fifteen minutes regardless. They are ceilings, not targets.
Is an iteration the same as a sprint?
Nearly. Iteration is the general agile term for a timeboxed cycle and comes from Extreme Programming. Sprint is Scrum's name for the same thing, with the additional requirements Scrum places on it: a Sprint Goal, a fixed length of a month or less, and a new one beginning as the last ends. SAFe uses iteration rather than sprint. In casual use they are interchangeable; in a Scrum context, sprint carries the extra rules.
What is an IP sprint?
An Innovation and Planning iteration, from SAFe. It is a cadence buffer at the end of a Program Increment, typically a couple of weeks, used for planning the next increment, innovation time, and the integration and infrastructure work that gets squeezed out of delivery iterations. It is a SAFe concept, not a Scrum one, and there is no equivalent in the Scrum Guide.
How long should a sprint be?
A month or less, and the same length every time. Two weeks is the commonest choice. Shorter sprints give faster feedback and more overhead per unit of work; longer ones give the reverse and let problems hide longer. The length matters less than keeping it constant, because a changing sprint length makes it impossible to tell whether anything is improving.
Can a sprint be canceled or extended?
Canceled, yes, if the Sprint Goal becomes obsolete, and only the Product Owner can do it. Extended, no. Extending a sprint to finish unfinished work removes the fixed cadence that makes the cycle useful and hides the fact that too much was taken on. Unfinished items return to the Product Backlog and are reconsidered.
How do you cite sprint practice?
For the sprint and its events, cite the Scrum Guide, giving the year, since the 2020 revision changed the vocabulary: Schwaber, K. and Sutherland, J. (2020) The Scrum Guide. For iterations as the general agile term, cite Beck, K. (1999) Extreme Programming Explained. For the IP iteration, cite the SAFe body of knowledge, which is separate from Scrum.
Deep Resources
Frameworks related to the Sprint Cycle
- Scrum FrameworkWho is accountable for what, and what the framework actually specifies…
- KanbanContinuous flow for work that will not wait for a sprint boundary…
- User Story MappingStructure for the backlog the cycle assumes is already ordered…