Sprint

A sprint is a time-boxed iteration — typically 2 weeks — in which a team commits to completing a defined scope of work. Sprints are the fundamental unit of Agile delivery: work is planned, executed, reviewed, and improved within a fixed cadence rather than a sequential waterfall of phases.

The fixed timebox is the critical constraint. A sprint doesn’t end when the work is done — it ends on Friday (or whenever the two-week window closes). If work isn’t done, it wasn’t done. The sprint review surfaces that fact so the team can adjust either the scope or the process.

Concrete example

A 6-person engineering team runs 2-week sprints. Sprint 14 runs from Monday the 5th to Friday the 16th. On Monday, they run Sprint Planning: pull user stories from the backlog, estimate story points, and commit to 34 story points for the sprint. Each team member takes responsibility for specific stories.

On the Friday of week 2: Sprint Review shows 29 of 34 story points shipped. One story (5 points) moved back to the backlog — QA found a blocking bug after Wednesday’s code freeze. Sprint Retrospective: the team agrees to tighten the code-review process to catch integration bugs earlier.

Sprint 15 starts Monday. The 5-point unfinished story goes back into backlog, re-estimated, and may be pulled into Sprint 15 during planning.

Why it matters

The sprint cadence forces three things that waterfall doesn’t:

1. Regular delivery: Something ships every two weeks, even if it’s a small increment. Stakeholders see progress; engineers don’t disappear into a six-month tunnel.
2. Scope control: The timebox prevents “just one more feature” syndrome. Adding scope mid-sprint requires removing an equivalent story — the trade-off is explicit.
3. Regular retrospection: The retrospective at the end of every sprint is the forcing function for process improvement. Teams that don’t retrospect don’t improve; they just complain.

The failure mode: sprints that run but don’t actually ship a review-able increment. If the sprint ends with “we’re 80% done” every time, the sprint is a reporting cadence, not a delivery cadence. The sprint review should produce something the product owner can actually test.

Tools that handle sprints natively

• Jira (£6.50/seat Standard) — the gold standard for sprint management: backlog grooming, velocity charts, burndown, sprint planning view, story-point estimation
• ClickUp Business (£10/seat) — native sprint board with burndown, velocity tracking, and GitHub integration; closest Jira equivalent at the same price point
• Linear (£8/seat) — cycles (Linear’s term for sprints) with clean velocity tracking and keyboard-first UI; faster than Jira for small engineering teams

Tools that simulate sprints but don’t enforce them

• monday.com — no native sprint board; you can build a sprint-like workflow with automations, but it’s not Agile-native and doesn’t track velocity or burndown
• Asana — no native sprint board at any tier; the timeline view can model sprint dates but there’s no story-point estimation, velocity tracking, or burndown chart
• Trello — no sprint concept; you can label columns with sprint numbers, but there’s no automation or tracking

Related concepts

• Sprint Planning — the meeting at the start of each sprint where the team pulls stories from the backlog and commits to scope
• Burndown Chart — the remaining-work-vs-time chart that shows whether the sprint is on track to deliver its committed story points
• Retrospective — the end-of-sprint ceremony where the team reflects on what worked and what to change next sprint