Skip to content

sprint

A sprint is a fixed-length stretch of time, usually one or two weeks and never longer than a month, in which a team commits to a focused batch of work and aims to finish it to its definition of done. It is the basic unit of cadence in Scrum, the most common way teams put agile ideas into practice.

Sprints run back to back with no gap, which gives a team a steady rhythm to plan and measure against:

Three equal sprint boxes (41, 42, 43) in a left-to-right row joined by solid "no gap" arrows, with a yellow "Same fixed length" box connected by dotted "each timebox" arrows to all three.
Equal-length sprints butt up against each other with no gap, the steady cadence a team plans against.
Language: Text
Sprint 41   Mon Jun 01  ->  Fri Jun 12    goal: ship CSV export
Sprint 42   Mon Jun 15  ->  Fri Jun 26    goal: add saved filters
Sprint 43   Mon Jun 29  ->  Fri Jul 10    goal: harden the import path

Each sprint carries a single sprint goal, the one outcome that makes the batch of work hang together and gives the team a clear answer to what the sprint is for.

How It Shows Up in Practice

A Python developer lives the sprint as the window their tickets are scheduled into, tracked on a board in Jira, Azure Boards, or Linear. At sprint planning the team pulls a user story from the backlog, sizes it in story points, and commits to what fits the timebox. A daily standup keeps everyone aligned, and the sprint closes with a review and a retrospective.

Holding the length fixed is the whole point. When every sprint is the same size, a team learns how much it can realistically finish in one and plans the next from real numbers instead of guesses.

Working Within the Timebox

To protect that focus, the team does not add work mid-sprint that would endanger the sprint goal. Scope can still be clarified and renegotiated with the product owner as the team learns more, and quality is never the corner that gets cut to hit the date.

If the goal itself becomes pointless, say the feature behind it is canceled, the product owner can end the sprint early, though that is rare. Teams that would rather keep a continuous flow of work without these fixed timeboxes use Kanban instead.

Course

Test-Driven Development With pytest

In this hands-on course, you’ll see how to create Python unit tests, execute them, and find the bugs before your users do. You’ll learn about the tools available to write and execute tests, check your application’s performance, and even look for security issues.

intermediate testing

For additional information on related topics, take a look at the following resources:


By Martin Breuss • Updated June 22, 2026