What is a sprint?
A sprint is a fixed time period, typically one to four weeks, during which a team commits to completing a defined set of work items from the backlog. Sprints are the heartbeat of the scrum framework. Each sprint begins with a planning session where the team selects what to build, continues with daily execution, and ends with a review of completed work and a retrospective on the process.
The defining characteristic of a sprint is its fixed duration. Once the team agrees on a sprint length - two weeks is the most common - that cadence does not change. This regularity creates a rhythm that stakeholders can rely on for updates, that product owners can use for planning, and that the team can use to calibrate how much work they can realistically take on.
Why sprints work
Sprints solve the problem of scope creep by creating hard boundaries. Once a sprint begins, the committed scope is locked. New requests go into the backlog for the next sprint, not into the current one. This protects the team from the constant reprioritization that kills focus and makes delivery unpredictable. The sprint boundary also creates accountability: at the end of each sprint, the team must demonstrate what they completed, which prevents work from drifting indefinitely.
The fixed cadence also makes capacity planning straightforward. After a few sprints, the team develops a velocity - the average amount of work completed per sprint. This historical data makes it possible to answer questions like "how many sprints will the remaining backlog take?" with reasonable accuracy, without requiring detailed estimation of every individual item.
Sprint length considerations
Two-week sprints are the industry default and work for most teams. One-week sprints suit teams with fast-moving requirements or those learning scrum for the first time, since the shorter feedback loop exposes process problems faster. Three- or four-week sprints suit teams working on complex features that are difficult to decompose into smaller increments. The trade-off is always between feedback speed (shorter sprints) and execution efficiency (longer sprints give more uninterrupted work time relative to ceremony overhead).
How Flux supports sprint workflows
Flux is a kanban platform at its core, so it does not enforce sprint boundaries or time-boxed iterations natively. However, teams running sprints can model the workflow effectively using Flux's customizable boards. A common setup uses columns like Sprint Backlog, In Progress, Review, and Done, with labels to tag cards by sprint number (Sprint 14, Sprint 15). At the start of a new sprint, cards are pulled from the backlog into the Sprint Backlog column. The activity log tracks every card movement with timestamps, providing the raw data teams need for sprint reviews. For teams using the sprint board template, the structure is ready to go from the first board.
Related terms
See also: Sprint Planning, Scrum, Velocity.