Sprint #

A serious engineering team isn’t measured by how many tasks it finishes each week, but by how fast it can learn and deliver real value to users. The sprint — as Scrum’s core mechanism — is designed exactly for that need. But in practice, sprints are often run as administrative rituals: planning, standup, review, retro — all done, yet the essence is lost. This article covers sprints comprehensively: from the most misunderstood philosophy, to all the activities within them, to the concrete anti-patterns you should avoid.

What Is a Sprint? #

A sprint is a fixed time period (time-boxed) during which the team works on a set of work items chosen from the Product Backlog, then produces something finished, tested, and ready to ship. This is what’s called an Increment — the smallest unit of value that can be demonstrated and evaluated.

Sprint duration has several options, each with trade-offs:

Three sprint properties that must never be violated:

• Consistent — duration doesn’t change every time there’s deadline pressure
• Predictable — scope is adjusted to team capacity, not stakeholder wishes
• Iterative & Incremental — every sprint produces something evaluable, not “still in progress”

A sprint whose duration changes every time deadline pressure hits isn’t a sprint — it’s firefighting packaged under an agile name. Duration consistency is the foundation of team predictability.

The Sprint Goal — The Most Misunderstood Part #

This is the biggest source of failure in Scrum adoption. Many teams diligently run all the rituals, but misunderstand why sprints exist. As a result, all sprint activities run as formalities without producing learning or real value.

Sprints Aren’t for Finishing Tasks #

Look at how sprints are usually measured in your team:

// ANTI-PATTERN: sprint measured by finished task count
Sprint 12 Summary:
  ✗ 23 of 25 stories finished (92% completion rate)
  ✗ Velocity: 48 SP
  ✗ "Sprint successful!"

// CORRECT: sprint measured by delivered value and learning gained
Sprint 12 Summary:
  ✓ Sprint Goal: "Users can check out without CS assistance"
  ✓ Increment: new checkout flow live on staging, ready to demo to stakeholders
  ✓ Insight: turns out users struggle at the payment step — backlog updated

Sprints aim to produce a valuable Increment and get feedback as fast as possible, not to finish every item in the sprint backlog.

The Sprint Goal Is the Center of Everything #

The Sprint Goal is the reason this sprint exists. It isn’t a task list to complete — it’s the problem to solve or the value to test in this sprint.

// ✗ A bad Sprint Goal — this is a task list, not a goal

"Implement the login feature, profile page, and email notifications"

// ✓ A good Sprint Goal — this is a problem to solve

"Users can create an account and log in to the app without admin assistance"

// ✗ A bad Sprint Goal — too vague, not measurable

"Improve application performance"

// ✓ A good Sprint Goal — specific and measurable

"Reduce the homepage load time from 4 seconds to under 1.5 seconds"

With a clear Sprint Goal, the team can make trade-offs when obstacles arise. If stories A and B can be finished but story C hits a blocker, the team can decide: can the Sprint Goal still be achieved without C? Without a Sprint Goal, all stories feel equally important and there’s no basis for decisions.

Sprints Are Experiments, Not Contracts #

The mistaken mindset treats a sprint as an absolute promise to management. This turns the sprint into a source of stress, overcommitment, and rushed code written to chase numbers.

// ANTI-PATTERN: sprint as a contract
  Sprint = a promise that must be 100% fulfilled
  If a task isn't finished = the team failed
  Velocity must rise every sprint

// CORRECT: sprint as a controlled experiment
  Sprint = an experiment to test assumptions and produce value
  Stories may go unfinished if the Sprint Goal is still achieved
  Velocity is an observational metric, not a KPI target

A sprint provides a safe space to try solutions, discover problems early, and correct course before it’s too late. A good sprint may fail technically, but it must not fail to learn.

The Sprint’s Relationship with Scrum #

Scrum is the framework; the sprint is its container. Within one sprint, there’s a series of structured, interdependent activities. Removing any one of them makes the sprint lose an important mechanism.

flowchart TD
    G["Backlog Refinement\nmid-sprint"]
    P["Sprint Planning\nsprint kickoff"]
    E["Sprint Execution\ndev + testing + daily scrum"]
    T["Test / Scenario Review\ninternal validation"]
    R["Sprint Review\nstakeholder feedback"]
    RT["Sprint Retrospective\nreflection on how the team works"]

    G --> P --> E --> T --> R --> RT
    RT --> |next sprint| P
    G -.->|prepares the backlog| P

These six activities aren’t formalities — each has a specific purpose:

Product Backlog Refinement (Sprint Grooming) #

Many teams go straight into Sprint Planning without adequate backlog preparation. As a result, planning becomes long and unproductive because requirement discussions that should have been finished beforehand happen there. Grooming — or Product Backlog Refinement — is the activity of preparing the backlog so that the stories to be taken in the next sprint are already clear, broken down small enough, and estimated.

When and How Often #

// ✓ Recommended timing
  Mid-current-sprint (e.g. day 5 of a 2-week sprint)
  1-2 times per sprint, 1-1.5 hours each
  Before the sprint nears its end so the backlog is always ready

// ✗ Problematic timing
  Grooming merged with Sprint Planning (planning becomes 4+ hours)
  Grooming only done when the backlog is empty (reactive, not proactive)

Activities in a Grooming Session #

An effective grooming session isn’t just reading the story list one by one. Several substantive activities should happen within it:

• Discussing user stories in detail with the Product Owner to ensure everyone has a shared understanding
• Clarifying ambiguous requirements before they enter a sprint, not while coding
• Breaking large stories (epics) into smaller stories completable within one sprint
• Estimating effort with Story Points — this is a brief technical discussion, not form filling
• Identifying dependencies between stories and technical risks that could hinder execution

Expected Outputs #

Stories leaving grooming must meet the Definition of Ready (DoR) — criteria stating a story is ready for the team to take. Without a DoR, stories entering a sprint are often still ambiguous and become sources of mid-sprint blockers.

// Example Definition of Ready (DoR)
REQUIREMENTS:
  □ User story uses the team-agreed format
  □ Acceptance criteria exist, are clear, and measurable
  □ Wireframes / designs available if the story involves UI

TECHNICAL:
  □ Story broken down — completable within one sprint
  □ Dependencies identified (other team APIs, data team data, etc.)
  □ Story Point estimate agreed after technical discussion

BUSINESS:
  □ Product Owner has validated the story's relevance to the current roadmap
  □ Priority set relative to other backlog stories

Backlog Refinement Anti-Patterns #

// ✗ Stories taken even when requirements are still ambiguous

"We'll figure out the details while coding"
// ✓ Stories must not enter a sprint until acceptance criteria are clear

// ✗ Estimation done without technical discussion

"This story is 3 points, on to the next one"
// ✓ Estimation is a brief technical discussion, not filling in number forms

// ✗ Grooming attended only by the Product Owner and Scrum Master
// ✓ Developers must attend — they know the technical complexity best

Sprint Planning #

Sprint Planning is the official kickoff of every sprint. This is where the team decides what will be done and how it will be done during the sprint. Good Sprint Planning takes no more than 2-4 hours for a 2-week sprint. If it’s longer, the backlog wasn’t refined enough.

Two Core Questions #

Sprint Planning is organized around two questions that must be answered before the team starts executing:

flowchart LR
    A{Sprint Planning} --> B["What can be delivered?\n→ Pick stories from the backlog\n→ Set the Sprint Goal"]
    A --> C["How will it be done?\n→ Break stories into technical tasks\n→ Discuss implementation approaches"]
    B --> D[Sprint Backlog takes shape]
    C --> D

Determining Team Capacity #

One of the first Sprint Planning steps is calculating realistic capacity. Many teams skip this and immediately take as many stories as possible — leading to overcommitment and sprints that always fail.

// Example team capacity calculation
Team: 4 developers, 2-week sprint (10 working days)
Assumed effective working hours: 8 hours/day

Per-person reduction factors:
  - Meetings & syncs: ~1 hour/day
  - Developer A PTO: 2 days
  - Sprint ceremonies (planning, review, retro): ~3 hours total

Actual capacity:
  Developer A: (8 days × 7 hours) = 56 hours
  Developer B: (10 days × 7 hours) = 70 hours
  Developer C: (10 days × 7 hours) = 70 hours
  Developer D: (10 days × 7 hours) = 70 hours

Total capacity: 266 hours
→ Convert to Story Points using the team's historical velocity
→ Reserve ~20% buffer for unexpected items and code reviews

Team capacity is calculated from actual data, not assumptions. Use the previous sprint’s velocity as a baseline. New teams without historical data should take fewer stories in the first sprint, then calibrate from there.

Sprint Planning Anti-Patterns #

// ✗ Sprint Goal too vague or missing entirely
Sprint Goal: "Work on the existing backlog"
// ✓ A Sprint Goal must answer "why is this sprint important?"

// ✗ Overcommitment due to management or stakeholder pressure

"The stakeholder wants features X and Y finished this sprint"
// ✓ Commit based on capacity and historical data, not requests

// ✗ Planning turning into a design or architecture meeting

"We should use this approach, let's discuss the architecture first..."
// ✓ Technical design is discussed at grooming — planning focuses on scope and goal

Sprint Execution #

Sprint Execution is the phase where the team works the sprint backlog — from the first line of code to the feature ready for review. This is the longest and most critical phase of the sprint, because this is where all plans meet reality.

The Finish Before Start Principle #

The most fundamental principle in healthy execution is finishing one story before starting another:

// ANTI-PATTERN: starting many stories at once
Developer A: story 1 (50%), story 3 (30%), story 7 (10%)
→ Nothing finishes mid-sprint
→ WIP (Work in Progress) piles up, nothing to demonstrate at sprint review

// CORRECT: focus on finishing one story before starting another
Developer A: story 1 (100%) → story 3 (70%) → ...
→ The Increment grows every day
→ If the sprint ends earlier than expected, there's always a truly Done story

A story that’s 90% complete delivers no value — only a truly Done story can be demoed and deployed.

Daily Scrum #

The Daily Scrum is a daily meeting of at most 15 minutes to synchronize the team’s work — not a status report to the manager. The format can be flexible, but the purpose is always the same: the team knows who is working on what and what’s blocking them.

// ✗ Wrong Daily Scrum: status update to the manager

"Yesterday I implemented endpoint A, it's 70% done. Today I continue endpoint A."
Manager: "Why isn't it done? The estimate was 2 days."

// ✓ Correct Daily Scrum: team synchronization for collaboration

"Endpoint A is almost done but needs input from [Dev B] on the response format.
If we can align now, it can be finished today."

If the team already has an always-updated board, the daily can focus on blocker discussions and coordination between interdependent stories — not just reading statuses aloud.

Maintaining Quality During Execution #

Sprint pressure often makes teams take shortcuts in code quality. This feels cheap in the current sprint but is expensive in the following sprints, in the form of production bugs and technical debt.

// Practices that must not be compromised during execution
  ✓ Unit tests written alongside implementation, not after finishing
  ✓ Code review done before a story is considered Done
  ✓ No "fix later" code without a clear ticket
  ✓ If you find a bug outside the story's scope, create a new ticket — don't silently fix it
  ✓ No merges to the main branch without a passing CI pipeline

Test / Scenario Review #

Test Scenario Review is an activity often skipped or assumed to be covered by the Sprint Review. In fact, the two have different functions: Test Scenario Review focuses on technical and functional validation before the stakeholder demo — it’s not a replacement for the external feedback loop.

Why It Matters #

Teams that skip Test Scenario Review often discover new bugs or edge cases at the Sprint Review — right in front of stakeholders. Besides damaging trust, this wastes the time of everyone present.

sequenceDiagram
    participant Dev as Developer
    participant QA as QA Engineer
    participant PO as Product Owner
    participant Stake as Stakeholder

    Dev->>QA: Story done, enters the testing queue
    QA->>Dev: Bug found (in the internal environment)
    Dev->>QA: Bug fixed
    QA->>PO: Scenario review — validate acceptance criteria
    PO->>QA: Flow matches expectations
    QA-->>Stake: Sprint Review — demo the validated increment
    Stake-->>PO: Feedback for the backlog

Activities Performed #

This session usually involves the developer, QA, and Product Owner — three different perspectives looking at the same feature:

• The developer explains what was implemented and the technical assumptions made
• QA runs test cases and discusses edge cases that might have been missed
• The Product Owner validates whether the flow matches the agreed acceptance criteria

Test Scenario Review Anti-Patterns #

// ✗ QA only becoming a "bug finder" the day before the Sprint Review
Testing starts too late → bugs found but no time for fixes
// ✓ Testing starts as soon as the first story is Done
Story done → immediately enters the testing queue → bugs fixed within the same sprint

// ✗ Acceptance criteria not used as the testing reference
QA writes test cases on their own without referencing acceptance criteria
→ Feature "passes QA" but doesn't match the Product Owner's expectations
// ✓ Acceptance criteria are the single source of truth for testing

Sprint Review #

The Sprint Review is the moment the team shows the sprint’s work results to stakeholders and gets real feedback. This isn’t an internal meeting — it’s the feedback loop between the team and the outside world. Sprint review quality greatly determines how relevant the backlog is for subsequent sprints.

Distinguish Sprint Review from Status Meetings #

This is the most common mistake: the Sprint Review run as a numbers report instead of a demonstration of the real increment.

// ✗ Sprint Review as a status report

"In this sprint we managed to finish 18 of 20 stories (90%).
Two stories carry over to the next sprint due to a technical blocker."
→ No demo, no feedback, no value received by stakeholders

// ✓ Sprint Review as a feedback loop

"This is the new checkout flow we built this sprint."
[Live demo in the system]

"We'd like to know: does this match your expectations? Anything to change?"
→ Stakeholders give concrete feedback
→ The backlog is updated based on new insights gained

Who Attends #

The Sprint Review is most effective when attendees are people who can make business decisions and give meaningful feedback:

// ✓ Must attend
  The entire Scrum team (developers, QA, Scrum Master)
  Product Owner

// ✓ Recommended to attend
  Business stakeholders who can give direct feedback
  End users if possible (light user testing)

// ✗ No need to attend
  Managers who only listen to reports without giving feedback
  Departments not involved with this sprint's increment

Sprint Review Outputs #

A successful Sprint Review produces more than just validation. It produces a clearer direction for the next sprint:

• An increment validated by stakeholders — the team knows this increment is relevant
• A backlog updated based on feedback (new stories, changed priorities, or old stories removed because they’re no longer relevant)
• The team and stakeholders aligned on the product’s current state and what to work on next

Sprint Retrospective #

The Retrospective is the only sprint activity entirely focused inward: not on the product, but on how the team works. This is Scrum’s main mechanism for continuous improvement. A team that skips retrospectives is a team that has stopped learning.

Commonly Used Formats #

Several formats are available. The simplest uses three questions:

What went well?       → What went well and should be kept?
What didn't go well?  → What didn't go well and needs improvement?
What can we try?      → Concrete action items for the next sprint?

The Start / Stop / Continue format is slightly more structured and forces the team to make decisions:

START    → New things we need to start doing
STOP     → Things we're currently doing that provide no value
CONTINUE → Things already going well that should continue

For more mature teams, 4Ls can produce deeper discussion:

Liked    → What did you like about this sprint?
Learned  → What did you learn?
Lacked   → What was missing and should have been there?
Longed For → What do you wish for that isn't there yet?

Effective Retrospectives vs Empty Formalities #

// ✗ A retrospective that's become a formality

"OK, we're at 45 minutes, does anyone have anything to say? No? See you next sprint."
→ Action items: none
→ Changes that happened: none
→ Next sprint: the same problems repeat

// ✓ A retrospective producing real change
Identify a specific problem: "Code reviews pile up at the end of the sprint"
Root cause: no SLA for how long a review should take
Action item: "Starting this sprint, every PR must get its first review within 4 working hours"
Owner: [Developer name] will remind if any PR sits idle for more than 4 hours
Tracking: this action item is reviewed at the next sprint's retrospective

Retrospective Anti-Patterns #

// ✗ Action items without owners and deadlines

"We need to improve documentation"
// ✓ Every action item has a clear owner and deadline

"[Developer A] will create a technical documentation template before the next Sprint Planning"

// ✗ Retrospectives repeatedly discussing the same problem sprint after sprint
Sprints 5, 6, 7, 8: "Testing is always rushed at the end of the sprint"
→ Action items never followed up on or ineffective
// ✓ Review previous retrospectives' action items at the start of every session

"Last sprint we committed to X — was it done? What were the results?"

// ✗ Only technical problems discussed
// ✓ Process, communication, and team dynamics matter as much as technical problems

A retrospective that produces no change is more dangerous than having no retrospective at all. It creates cynicism — the team feels their voices aren’t heard and meetings just waste time. If action items from the last 3 retrospectives haven’t been done, figure out why before adding new ones.

Definition of Ready and Definition of Done #

DoR and DoD are two written contracts that let sprints run predictably. Without them, “ready” and “done” become subjective and a source of recurring conflict.

Definition of Ready (DoR) #

The DoR defines when a story is fit to enter a sprint. Stories not meeting the DoR must not be taken at Sprint Planning — no matter how hard management pressures.

// Example DoR for a web application team

REQUIREMENTS:
  □ User story written in the team-agreed format
  □ Acceptance criteria exist, clear, and measurable
  □ Wireframes / designs available if the story involves UI changes

TECHNICAL:
  □ Story broken down — completable within one sprint
  □ Dependencies identified (APIs from other teams, data team data, etc.)
  □ Story Point estimate agreed after technical discussion

BUSINESS:
  □ Product Owner has validated this story is still relevant to the current roadmap
  □ Priority set relative to other backlog stories

Definition of Done (DoD) #

The DoD defines when a story is truly finished. “Done” isn’t just code running on a developer’s laptop — it covers the entire cycle from code to ready-for-production deployment.

// Example DoD for a team deploying to production

CODE:
  □ Code pushed to the main branch (not just a local or feature branch)
  □ Code review done and approved by at least 1 other developer
  □ No unresolved merge conflicts

TESTING:
  □ Unit tests written for new business logic
  □ All tests (unit, integration) pass in the CI pipeline
  □ QA has tested based on the acceptance criteria

DEPLOYMENT & MONITORING:
  □ Feature deployed to the staging environment
  □ Smoke test on staging done and passed
  □ Logging and monitoring configured for the new feature (if relevant)

DOCUMENTATION:
  □ API documentation updated if the contract changed
  □ README or internal wiki updated if configuration changed

Why DoR and DoD Must Be Built Together with the Team #

// ✗ DoR and DoD created by the Scrum Master or PO alone, then announced to the team
→ The team doesn't feel ownership
→ Not followed consistently
→ Becomes a document that exists only on paper but doesn't live in daily work

// ✓ DoR and DoD created in a workshop with the entire team
→ Every team member contributes → more followed and more relevant
→ Reviewed and updated quarterly or when the technology stack changes
→ Posted somewhere accessible — not just in an unread Confluence page

The Complete Sprint Flow #

To visualize how all activities connect in one 2-week sprint cycle:

gantt
    title 2-Week Sprint Flow
    dateFormat  D
    axisFormat Day %d

    section Sprint N-1
    Sprint N Grooming           :done, g, 5, 2d

    section Sprint N
    Sprint Planning             :active, p, 1, 1d
    Sprint Execution            :e, 2, 7d
    Test / Scenario Review      :t, 7, 2d
    Sprint Review               :r, 10, 1d
    Sprint Retrospective        :rt, 10, 1d
    Sprint N+1 Grooming         :gn, 6, 2d

Patterns to notice:

• Grooming for the next sprint happens mid-current-sprint — not when the sprint is almost over
• Testing starts as soon as possible after the first story is Done, not waiting for all stories to finish
• Sprint Review and Retrospective happen on the same day (the sprint’s last day), but with different focuses

Anti-Patterns to Avoid #

Here are sprint-level anti-patterns — not just in one activity, but in how the team views the sprint as a whole:

// ✗ Sprints used to promise features to clients

"This feature will definitely be done this sprint, we've added it to the sprint backlog"
// ✓ A sprint is an internal team commitment, not an external promise

// ✗ Velocity used as an individual developer performance KPI

"Developer A's velocity is 12 SP, Developer B's is only 8 SP — so A is more productive"
// ✓ Velocity is a team metric, not an individual one. Story Points aren't working hours.

// ✗ Sprint Planning done without capacity data

"Let's take everything in the backlog and hope there's enough time"
// ✓ Calculate actual capacity first, take stories based on historical data

// ✗ Retrospectives skipped when the sprint is busy

"This sprint is packed, let's skip the retro for now"
// ✓ The busiest sprint is exactly the one most needing a retrospective

// ✗ Stories carried over without root cause analysis

"This story isn't done, just move it to the next sprint"
// ✓ Every carry-over is analyzed — was the estimate wrong? Was there a preventable blocker?

// ✗ Sprints used as a tool to pressure developers

"You must finish this before the sprint ends, no matter what"
// ✓ A sprint is a collaboration tool, not a management pressure tool

Healthy Sprint Checklist #

BACKLOG & GROOMING:
  □ Backlog refined before Sprint Planning
  □ Stories entering the sprint meet the Definition of Ready
  □ Inter-story dependencies identified and mapped

SPRINT PLANNING:
  □ Sprint Goal set and understood by the entire team
  □ Capacity calculated from actual data (historical velocity + PTO)
  □ Team not overcommitted — ~20% buffer for unexpected items

SPRINT EXECUTION:
  □ Daily Scrum held every day, max 15 minutes
  □ Blockers raised and resolved the same day
  □ Stories worked one at a time (finish before start)
  □ Code reviews don't pile up at the sprint's end

TESTING & REVIEW:
  □ Testing starts from the first Done story, not at the sprint's end
  □ Test Scenario Review done before the Sprint Review
  □ Sprint Review involves stakeholders who can give real feedback

RETROSPECTIVE:
  □ Retrospective held every sprint without exception
  □ Action items have clear owners and timelines
  □ Previous retrospectives' action items reviewed at session start
  □ The team feels safe speaking honestly (psychological safety maintained)

DOD & DOR:
  □ Definition of Ready honored at Sprint Planning
  □ Definition of Done honored before a story is considered finished
  □ DoR and DoD reviewed periodically (at least quarterly)

Summary #

• A sprint is an experiment, not a contract — commit to the Sprint Goal, not to every backlog item. Stories may go unfinished if the Sprint Goal is still achieved.
• The Sprint Goal is the center of everything — without a clear Sprint Goal, a sprint is just an aimless task list. A good Sprint Goal answers “what problem does this sprint solve?”
• Grooming is an investment, not overhead — stories entering a sprint unprepared become sources of blockers and overruns mid-sprint.
• Capacity is calculated, not assumed — overcommitment is the main cause of failed sprints. Use historical velocity and account for PTO before taking stories.
• Daily Scrum is team synchronization, not a report to superiors — focus on blockers and coordination, not individual progress reports.
• Testing starts as soon as the first story is Done — not the day before the Sprint Review. Bugs found earlier are far cheaper to fix.
• Sprint Review is a real feedback loop — not a status report. Demo directly to stakeholders, collect feedback, update the backlog based on new insights.
• A retrospective without action items is an empty formality — every identified problem must have a concrete action, owner, and timeline.
• DoR and DoD are the team’s written contracts — build them together, honor them together, review them periodically.
• Velocity is an observational metric, not a target — optimizing velocity without optimizing value is the most dangerous form of agile cargo cult.

← Previous: Avoid Over-Indexing   Next: Workflow →