Skip to main content
← Back to the libraryMethods

Sprint

A sprint is a fixed-length work cycle, typically one to four weeks and most often two, that ends with a concrete, usable result.

The term comes from Scrum, the agile framework widely used in software and product work. At the start of a sprint, the team agrees on which tasks it will tackle during that window, known as the sprint backlog. That list stays locked for the duration of the sprint, and new requests get queued for the next cycle instead of interrupting the current one. Every sprint closes with a sprint review, where the team shows what it actually finished, followed by a retrospective focused on how to work better next time.

The fixed timebox is what makes a sprint work. It forces you to break tasks down small enough that they can genuinely be finished within the window, rather than dragging on for months. Sprint lengths typically range from one to four weeks, with a two-week rhythm the most common choice in practice. Shorter sprints mean more planning overhead, while longer ones delay feedback and let wrong assumptions run further before anyone catches them.

The pattern has spread well beyond Scrum, for example as a Design Sprint, where a five-day cycle is used to test a single idea, or simply as a recurring work rhythm in operations and administration. What all of these share is the same loop: set a goal, cap the time, deliver something, reflect, then start the next cycle. That is what separates a sprint from a milestone, which marks a single point in time rather than a repeating rhythm of work.

Practical Example

A six-person development team plans a two-week sprint to build a new reporting feature for their internal software, committing to 34 story points. By the end of the sprint, 29 points are done and get demoed live in the sprint review, while 5 points go back into the product backlog. In the retrospective, the team realizes that input from the business side came too late in the cycle, so they schedule an earlier check-in for the next sprint.

How Leanshift Helps

A sprint is Kaizen in miniature, a fixed, repeating rhythm of planning, doing, showing, and reflecting. Every retrospective is a deliberate pause to ask what could work better next cycle, instead of just pushing forward. That is the core of what Leanshift means by improving in order to create more people who improve: the result of a sprint matters, but so does what the team learns from each cycle.

Frequently Asked Questions

How long should a sprint be?

Somewhere between one and four weeks, with two weeks the most common choice. The exact length matters less than keeping it consistent across cycles so you get comparable data over time.

What happens to unfinished tasks at the end of a sprint?

They go back into the product backlog and get re-prioritized for a future sprint. New tasks are not added mid-sprint, since that would undermine the sprint goal.

How is a sprint different from a milestone?

A milestone marks a single important point in a project's timeline. A sprint is a recurring, equal-length work cycle with its own planning and review.