Sprints
Work in fixed time-boxes of a few weeks: pick a goal, build it, show it, look back, and start the next one.
How it works
A sprint is a fixed stretch of time in which a team commits to one goal and finishes usable work toward it. In Scrum, the framework that named it, a sprint lasts one month or less and the next one starts as soon as the last ends. It opens with Sprint Planning (at most eight hours for a one-month sprint), where the team picks items from the top of the product backlog and agrees a single Sprint Goal. Every day the developers hold a 15-minute Daily Scrum to adjust the plan. Nothing that would endanger the goal is added mid-sprint. At the end, a Sprint Review (at most four hours) shows the result to stakeholders, and a Retrospective (at most three hours) decides what the team will change about how it works. The Scrum Guide says nothing about story points or velocity. Many teams add them anyway: they size each item in relative points, add up the points finished per sprint (the velocity), and use the average of recent sprints to decide how much to take on next time. Not every team uses time-boxes. Kanban drops them for continuous flow with a limit on work in progress, and Basecamp’s Shape Up uses six-week cycles with a two-week cool-down.
Laps on a running track. Each lap is the same length, so you can see whether you are speeding up or slowing down, and every time you pass the coach you can change your pace.
Reach for it when
- Priorities change often and stakeholders need a regular point to steer
- A new team needs a rhythm for planning, demos and improving how it works
- You want frequent, predictable checkpoints with whoever is paying for the work
Think twice when
- Most of the work is unplanned interrupts, such as support or operations queues; a kanban flow fits better
- Velocity is used to compare teams or judge people: points then inflate and stop meaning anything
- The ceremonies have become the goal, and the team holds every meeting without shipping anything
A real example
A team of six works in two-week sprints. On Monday morning it plans: the goal is “customers can export invoices as PDF”, and it pulls eight backlog items worth 21 points, close to its recent average of 20. Each morning it spends 15 minutes on what is blocking the goal. A request for a new dashboard arrives mid-sprint and goes to the backlog instead. On the second Friday it demos the export to the finance team, who ask for a date filter (a new backlog item), and in the retrospective it agrees to split items larger than 8 points before planning.
Sprints, kanban and Shape Up#
Three common ways to pace product work. Many teams mix them.
| Scrum sprints | Kanban | Shape Up | |
|---|---|---|---|
| Cadence | Fixed sprints of one month or less, back to back | Continuous flow, no time-boxes | Six-week cycles, then two weeks of cool-down |
| How much work starts | What the team forecasts it can finish toward the Sprint Goal | Only as much as the WIP limit on each column allows | One shaped project per team, sized by appetite, not estimates |
| What gets measured | Progress toward the goal; many teams add velocity | Lead time and throughput | Whether the project shipped within its six weeks |
| Mid-period changes | Nothing that endangers the Sprint Goal | Reprioritise the queue at any time | The team is left alone for the cycle |
| Unfinished work | Returns to the product backlog | Stays on the board until done | Circuit breaker: not extended by default; reshaped instead |
| Fits | Product teams that want a steady rhythm of planning and review | Support, operations and other interrupt-driven work | Teams that can shape and scope a project before building it |
Story points and their critics#
Story points come from Extreme Programming, not Scrum. Ron Jeffries recalls that XP teams first estimated stories in time, then in “ideal days” multiplied by a load factor, and then simply called ideal days “points”: a three-point story meant about nine days. The abstraction was meant to stop people from treating estimates as promises.
In 2019 Jeffries wrote that he may have invented story points, “and if I did, I’m sorry now.” He thinks comparing teams on velocity or estimate quality is harmful, and advises dropping estimates altogether if they aren’t giving a team real value. Shape Up makes a similar choice: instead of asking how long work will take, it asks how much time the work is worth (its appetite) and cuts scope to fit.
Often confused with
Where it came from1986–2020
In January 1986 Hirotaka Takeuchi and Ikujiro Nonaka published “The New New Product Development Game” in Harvard Business Review. Studying product teams at companies such as Fuji-Xerox, Canon and Honda, they argued that winning now took speed and flexibility as well as quality and low cost, and they found it in small teams that worked through a project together, an approach they compared to a scrum in rugby.
Ken Schwaber and Jeff Sutherland took the rugby term for software. They first co-presented Scrum at the OOPSLA conference in 1995, and Schwaber’s paper described the Sprint as a pre-defined period of development, usually one to four weeks. In February 2001, seventeen people including Schwaber and Sutherland met at Snowbird, Utah, and wrote the Agile Manifesto. Schwaber and Sutherland published the first Scrum Guide in 2010; its 2020 revision is the current one.
Alternatives grew alongside. David Anderson’s 2010 book on the Kanban Method applied lean ideas to software: visualize the work and limit work in progress instead of planning in batches. In 2019 Basecamp published Shape Up, which kept a fixed time-box but stretched it to six weeks and dropped backlogs and daily meetings.
Why it’s built this way
- A fixed time-box
- Development is unpredictable, so instead of planning everything up front, Scrum inspects and adapts at least every calendar month. A fixed length makes each sprint a comparable experiment.
- Protect the goal during the sprint
- If priorities can change every day, nothing gets finished. Keeping out work that threatens the Sprint Goal gives the team a stable target while new ideas wait for the next planning.
- End every sprint with a review and a retrospective
- The review checks the product with stakeholders; the retrospective checks the process. Scrum treats both as feedback loops, which is the point of iterating.
- Kanban: limit work in progress instead of time
- When everyone is fully busy, work queues up and slows down, like a traffic jam. Capping work in progress keeps items flowing and makes bottlenecks visible.
Timeline
- 1986
Takeuchi and Nonaka publish “The New New Product Development Game” in HBR
- 1995
Schwaber and Sutherland first present Scrum at OOPSLA
- 2001
The Agile Manifesto is written at Snowbird, Utah
- 2010
First Scrum Guide; David Anderson’s book on the Kanban Method
- 2019
Basecamp publishes Shape Up; Ron Jeffries regrets story points
- 2020
Current revision of the Scrum Guide
- Takeuchi and Nonaka: The New New Product Development Game (Harvard Business Review, Jan 1986)
- Ken Schwaber: SCRUM Development Process (OOPSLA ’95 workshop paper)
- Agile Manifesto: History (Snowbird, February 11 to 13, 2001)
- Schwaber and Sutherland: The Scrum Guide (Nov 2020; history of Scrum and of the Guide)
- Open Library: David J. Anderson, Kanban (Blue Hole Press, 2010)
- Kanban University: The Official Kanban Guide (lean, WIP limits, pull systems)
- Jason Fried, Signal v. Noise: Announcing Shape Up (Jul 2019)
- Ron Jeffries: Story Points Revisited (May 2019)
Sources8
- The Scrum Guide (Nov 2020): sprints, events and timeboxes
- Ron Jeffries: Story Points Revisited (May 2019)
- Atlassian: Story points and agile estimation
- Atlassian: Velocity in Scrum (averaged over several sprints)
- Kanban University: The Official Kanban Guide (WIP limits, lead time, throughput)
- Shape Up: Introduction (six-week cycles, appetite, no daily meetings)
- Shape Up: The Betting Table (cool-down, circuit breaker, why not two-week cycles)
- Shape Up: Bets, Not Backlogs