Sprint
sprint
A fixed time period (usually 1-2 weeks) in which a team commits to completing specific work.
A sprint is a fixed time box (typically one or two weeks) during which a development team commits to completing a defined set of work. At the start of the sprint, the team selects items from the backlog. At the end, they demo what was completed and plan the next sprint.
Sprints create rhythm and accountability. Without time boxes, work expands to fill available time. Sprints force prioritization: if you only have two weeks, you cannot do everything, so you must choose the most important things. The constraint is the point.
The sprint model works well for teams building products with predictable requirements. It works poorly for teams doing mostly reactive work (support, incident response) or exploratory work (research, prototyping). Not every team needs sprints. Some teams use Kanban (continuous flow) instead.
Examples
A team plans a two-week sprint.
The team has 100 story points of capacity. They pull the top priorities from the backlog: 3 features (40 points), 2 bugs (15 points), 1 tech debt item (10 points), and buffer for unexpected work (35 points). They commit to the features and bugs, with tech debt as a stretch goal.
A sprint is disrupted by an urgent request.
Midway through the sprint, the CEO requests an urgent feature for a sales demo. The team discusses the tradeoff: adding this work means removing something else from the sprint commitment. They drop one planned feature and add the urgent request. The sprint scope change is visible and intentional.
A sprint retrospective identifies a pattern.
For three consecutive sprints, the team completes 70% of committed work. The retrospective reveals the cause: estimates are consistently optimistic and interruptions from support tickets are not accounted for. The team reduces commitments by 20% and allocates 15% capacity for support. The next sprint hits 95% completion.
In practice
Read more on the blog
Frequently asked questions
Should sprints be one week or two weeks?
Two weeks is the most common. One-week sprints have more overhead (planning, demos, retros consume a higher percentage of the sprint). Three-week or four-week sprints lose the urgency that makes sprints effective. Start with two weeks and adjust based on your team's rhythm.
What happens when sprint work is not completed?
Incomplete work rolls to the next sprint. This is normal and expected occasionally. If it happens every sprint, the team is over-committing. Reduce the amount of work committed per sprint until the team can consistently deliver on its commitments.
Related terms
The prioritized list of all planned work that a team has not yet started.
A brief daily team meeting where each member shares progress, plans, and blockers.
The amount of work a team completes per sprint, measured in story points or similar units.
A software development methodology that delivers work in short iterations with continuous feedback and adaptation.
An Agile framework that organizes work into fixed-length sprints with defined roles, ceremonies, and artifacts.
A meeting where the team selects which work to complete in the upcoming sprint and plans how to accomplish it.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.