Skip to content

Description

A Sprint is a short, fixed-length timebox in the Scrum framework during which a usable and potentially shippable product increment is created. Sprints are at the heart of Scrum and provide a regular rhythm for delivering value to customers. So it's:

  • A timeboxed development cycle (usually 1 to 4 weeks).
  • Always ends with a review and potential product release.
  • Work is based on items from the Product Backlog, selected during Sprint Planning.
  • No changes are made that would endanger the Sprint Goal.
  • Each Sprint should feel like a mini-project that moves the product forward in a meaningful way.

Sprint Lifecycle Overview

1. Sprint Planning

  • Marks the beginning of the Sprint.
  • The team decides what work will be done and how it will be accomplished.
  • A Sprint Goal is defined to give the Sprint a clear purpose.

2. Daily Scrum (Stand-up)

  • A 15-minute daily meeting.
  • Team members discuss:
    • What they did yesterday
    • What they’ll do today
    • Any blockers or issues

3. Sprint Work

  • The team works on the Sprint Backlog, a subset of Product Backlog items chosen for the Sprint.
  • Developers collaborate closely, test often, and update progress daily.

4. Sprint Review

  • Held at the end of the Sprint.
  • The team demonstrates the completed work to stakeholders.
  • Feedback is collected to refine the Product Backlog and future Sprints.

5. Sprint Retrospective

  • A team-only reflection after the review.
  • Discusses what went well, what didn’t, and how to improve.
  • Focused on continuous improvement.

A Sprint on a calendar

gantt
    title Two-week Sprint
    dateFormat YYYY-MM-DD
    axisFormat %d %b
    section Events
    Sprint Planning        :milestone, m1, 2026-03-02, 0d
    Daily Scrum, every day     :active, d1, 2026-03-02, 10d
    Sprint Review          :milestone, m2, 2026-03-13, 0d
    Sprint Retrospective   :milestone, m3, 2026-03-13, 0d
    section Work
    Development toward the Sprint Goal :2026-03-02, 10d
    Backlog refinement, about 10%      :2026-03-04, 8d

Key Principles of Sprints

  • Consistent Duration: Sprints should be the same length throughout the project to maintain rhythm.
  • No Scope Changes Mid-Sprint: Once a Sprint starts, its goal and backlog are fixed.
  • Done = Shippable: Work completed in a Sprint should be ready to release, even if not always released.
  • Focus and Commitment: The team commits to the Sprint Goal and works with focus to achieve it.

Benefits

  • Fast Feedback: Regular reviews let stakeholders respond to progress quickly.
  • Predictability: Fixed-length Sprints help with planning and forecasting.
  • Focus on Value: The Sprint Goal keeps the team aligned on delivering business value.
  • Continuous Improvement: Frequent retrospectives help the team evolve.

Challenges

  • Requires strict time management and discipline.
  • Teams may overcommit or undercommit.
  • Can be difficult if stakeholders interrupt the Sprint with changes.
  • Needs a strong Definition of Done to avoid technical debt.

When to Use Sprints

Sprints are ideal when:

  • You want frequent releases of working software.
  • You expect changing requirements.
  • Your team is collaborative and self-organizing.
  • You’re aiming for continuous delivery and feedback.

Sprint Events at a Glance

Event Timebox (1-month Sprint) Purpose Who
Sprint Planning 8 hours Pick the work, set the Sprint Goal Whole Scrum Team
Daily Scrum 15 minutes Re-plan the next 24 hours, surface blockers Developers
Sprint Review 4 hours Inspect the Increment, adapt the Product Backlog Team + stakeholders
Sprint Retrospective 3 hours Improve the process Scrum Team only

Shorter Sprints scale the timeboxes down proportionally: a 2-week Sprint gets roughly 4 hours of Planning, a 2-hour Review and a 90-minute Retrospective.

Note the split: the Review inspects the product, the Retrospective inspects the process. Merging them reliably means the process discussion gets dropped.

Cancelling a Sprint

A Sprint can be cancelled, only by the Product Owner, when the Sprint Goal becomes obsolete. This is rare. Incomplete items return to the Product Backlog. A Sprint is never cancelled just because the team will not finish everything. Unfinished items are simply re-ordered into a later Sprint.

Check Your Understanding

#

The Sprint Backlog turns out to be more work than the team can finish. What happens?

#

What is the difference between the Sprint Review and the Sprint Retrospective?