Sprint

Definition: A sprint is a fixed-length period — typically one to four weeks — during which a development team produces a usable, potentially releasable increment of product. Its defining property is the timebox: the end date is immovable, so when work exceeds capacity, scope flexes rather than the deadline. Every sprint carries a single Sprint Goal that gives the work coherence, and each sprint begins the moment the previous one ends, with no gaps.

How It Works

A sprint is not “two weeks of work.” It is a container with a fixed wall, a stated purpose, and a defined set of events. Remove any of those three and you have a status meeting cadence, not a sprint.

The Timebox Is the Whole Point

The timebox is the one rule that makes everything else in Scrum function. A sprint has a fixed duration decided in advance, and that duration does not change because the work is unfinished. If a team planned nine items and completed six, the sprint still ends on Friday. The three incomplete items go back to the Product Backlog, get re-estimated if their understanding changed, and are considered fresh in the next Sprint Planning.

This feels wasteful the first time it happens. It is not. The timebox does three jobs simultaneously:

Job	Mechanism	What breaks without it
Creates a forecasting baseline	Equal-length intervals make throughput comparable across sprints	Velocity becomes meaningless; you cannot compare a 9-day sprint to a 14-day one
Forces prioritization	Fixed capacity means someone must choose what does not fit	Everything is “in progress”; nothing finishes
Bounds risk	Maximum wasted investment before feedback is one sprint	A bad direction can run for months undetected

Extending a sprint by “just three days to finish” destroys all three at once. The velocity data becomes noise, the prioritization decision is dodged rather than made, and the feedback loop stretches. The extension also teaches the team that the deadline is negotiable, which means the next sprint’s plan is padded with the assumption of slack. Timebox discipline is not bureaucratic rigidity — it is what converts a calendar into a measuring instrument.

The corollary matters as much: scope is the variable. When a sprint is going badly, the response is to reduce scope, not to extend time or add hours. The team drops the lowest-value item, negotiates a thinner version of a story with the Product Owner, or ships the goal with less polish. What it does not do is work the weekend to preserve a plan that was a forecast, not a promise.

The Sprint Goal

A Sprint Goal is a single, coherent objective the sprint serves. It is written as an outcome, not a list. Compare:

Weak (a list)	Strong (a goal)
“Finish PROJ-441, PROJ-455, PROJ-460, and the logging ticket”	“A new user can sign up and complete checkout without contacting support”
“Do the sprint backlog”	“Cut p95 search latency below 300ms on the top three query shapes”
“Various improvements”	“Prove the payment provider migration works end to end in staging”

The goal exists so the sprint has meaning beyond ticket accounting. Three concrete consequences follow from having one:

It enables mid-sprint tradeoffs. When an item turns out to be twice as large as estimated, the team asks “does the goal still hold if we cut this?” With a goal, that question has an answer. Without one, every item looks equally load-bearing and the team either works overtime or drops something arbitrary.
It gives the Sprint Review a subject. A review of a goal is a conversation about whether the objective was met and what stakeholders think. A review of nine unrelated tickets is a demo queue.
It creates flexibility in the backlog. The Sprint Backlog can change substantially — items added, removed, resplit — as long as the goal is still being pursued. The goal is the commitment; the item list is the current best plan for reaching it.

A sprint without a goal degenerates predictably. The backlog becomes whatever happened to be at the top of the list on planning day: a config change, an unrelated bug, half of a feature, a spike, a dependency upgrade. Nothing connects, so nothing can be traded off against anything else, so every item must be finished, so the timebox becomes the thing under pressure. Goalless sprints are the single most common cause of teams that “do Scrum” and get nothing from it.

The goal should be narrow enough to be falsifiable at the end of two weeks and broad enough that more than one path leads to it. “Ship the checkout redesign” is usually too big. “Merge PR #882” is too small — that is a task, not an objective.

Sprint Planning

Planning is timeboxed too: a maximum of eight hours for a one-month sprint, proportionally less for shorter ones — roughly two hours per week of sprint length. Well-run planning for a two-week sprint takes two to four hours and answers three questions.

Topic	Question	Who leads	Output
Why	Why is this sprint valuable?	Product Owner proposes, team shapes	Sprint Goal
What	What can be done this sprint?	Whole team, PO clarifies value	Selected Product Backlog items
How	How will the work get done?	Developers	Decomposed plan, first days’ tasks

Planning is effective in direct proportion to how well Product Backlog and Refinement was done beforehand. If the team is discovering requirements during planning, planning turns into a four-hour requirements workshop and the resulting forecast is guesswork. Refinement is continuous work that happens throughout the sprint — typically five to ten percent of capacity — so that items entering planning are already understood, sized, and free of blocking unknowns.

Capacity is a forecast, not a contract. Teams typically use recent Velocity and Burndown Charts as a starting range, then adjust for known absences, on-call rotations, holidays, and support load. A team averaging 30 points that has two people on vacation should plan for roughly 22, not 30 with an intention to “push.”

The “how” portion matters more than teams expect. Decomposing the first few items into concrete tasks during planning surfaces disagreements about approach while there is still time to change the plan. A story that three developers each imagine differently will produce three days of rework when they collide in review.

Execution: The Daily Loop

Inside the sprint, the Developers self-manage. The one required event is the Daily Scrum: fifteen minutes, same time and place, for the Developers to inspect progress toward the Sprint Goal and adapt the plan for the next 24 hours. It is a planning session, not a status report to a manager. Its output is a changed plan — who pairs with whom, what gets swarmed, what blocker gets escalated today.

The signature failure of execution is the horizontal sprint: every item started in the first three days, nothing finished until the last two, and a burndown that stays flat then drops off a cliff. The remedy is limiting work in progress and swarming — finishing items one at a time rather than starting them all in parallel. A sprint that finishes five of nine items completely delivers more value than one that gets nine items to 80 percent, because 80 percent of a feature is worth zero.

The Closing Events

Two events close a sprint and they inspect different things.

Sprint Review — timeboxed to four hours for a one-month sprint. The team and stakeholders inspect the increment and discuss what to do next. It is a working session, not a presentation. Demonstrations run against real working software, not slides. The most valuable output is a changed Product Backlog: stakeholder reaction to what was built reshapes what gets built next. A review where nobody asks a hard question was probably a status update in disguise.

Sprint Retrospective — timeboxed to three hours for a one-month sprint. Covered in depth in Sprint Retrospective. It inspects the process, not the product: how the team worked, what helped, what got in the way. Its output should be at most one or two concrete improvements carried into the next sprint, ideally added to the Sprint Backlog so they compete for real capacity rather than living on a wishlist.

The increment is only real if it meets the Definition of Done. “Done” that means “code written, needs QA next sprint” is not done — it is unmeasured inventory, and it silently inflates velocity while accumulating a queue of unverified work.

Why It Matters

Timeboxing converts calendar time into a measuring instrument. Equal-length intervals make throughput comparable, which is the only reason velocity-based forecasting works at all. Variable-length sprints produce data you cannot use.
It bounds the maximum cost of being wrong. The worst case for a misjudged direction is one sprint of wasted effort before stakeholders see it and can redirect. That ceiling is what makes iterative delivery safer than a long single-pass plan.
It forces the prioritization conversation to actually happen. Fixed capacity means someone must decide what does not fit. Without a hard boundary, that decision gets deferred indefinitely and everything stays nominally in scope.
It creates a predictable cadence for the rest of the organization. Stakeholders know when they will see working software, when they can influence direction, and when they can expect answers. Predictability is often worth more to a business than raw speed.
The Sprint Goal gives the team autonomy over the how. Committing to an outcome rather than a task list lets developers change the plan freely as they learn, which is where most of the real productivity gain lives.
It surfaces systemic problems on a fixed schedule. A flaky test suite, a slow review culture, or an unresponsive dependency team causes a visible miss every two weeks instead of being absorbed silently into an open-ended schedule.
It creates a natural integration point. Producing a genuinely releasable increment every sprint forces the team to keep the build green, the migrations runnable, and the deployment path exercised. Teams practicing CI-CD find sprint boundaries cheap; teams without it find them brutal, which is exactly the diagnostic signal they need.
It protects the team from continuous re-direction. The convention that the Sprint Goal does not change mid-sprint gives developers a short but real stretch of uninterrupted focus. That protection is one of the main things a Scrum Master defends.
It makes overcommitment visible instead of invisible. A team that consistently plans 40 points and finishes 25 learns that within three sprints. Under an open-ended schedule, the same team just looks perpetually “almost done.”

Sprint Length: Choosing the Timebox

Sprint length is a real engineering tradeoff, not a default. Shorter sprints buy feedback frequency and pay in ceremony overhead. Longer sprints buy uninterrupted work time and pay in delayed learning and larger batches.

Length	Ceremony overhead	Feedback latency	Best suited to	Main risk
1 week	High — roughly 10 to 15 percent of capacity; planning, review, and retro land every week	Very fast; a wrong direction costs at most 5 working days	High-uncertainty product discovery, early-stage startups, teams fixing a badly broken process	Little room for anything larger than a small story; forces heavy slicing; retro fatigue sets in and quality of reflection drops
2 weeks	Moderate — roughly 5 to 8 percent	Fast; comfortable stakeholder rhythm	The default for most product teams; large enough for meaningful chunks, short enough to correct course	Long weekends and holidays eat a noticeable fraction of capacity; still tight for work with heavy external dependencies
3 weeks	Lower per unit of work	Moderate	Teams with genuinely long feedback cycles — hardware integration, regulated review, external partner dependencies	Awkward against monthly business rhythms; the middle week often loses urgency and drifts
4 weeks	Lowest	Slow; up to a month of investment before external validation	Environments with heavy compliance or approval gates; the Scrum maximum	Batches get large, mid-sprint plans go stale, and the temptation to change scope mid-sprint becomes severe

Practical guidance: start at two weeks. It is the point where most teams find ceremony cost tolerable and feedback fast enough. Move to one week when you are learning faster than you can act on — heavy discovery, an unstable process, a team that keeps discovering surprises at the review. Move to three or four only when a real external constraint makes a two-week increment impossible, not because ceremonies feel annoying.

Two anti-patterns around length:

Changing sprint length frequently. Every change resets your velocity baseline. If you must change, expect two or three sprints before the numbers mean anything again.
Treating a longer sprint as the fix for missing the goal. If a team cannot finish anything in two weeks, the problem is almost always item size, work-in-progress limits, or a Definition of Done that requires a slow manual gate. A longer sprint hides those problems; it does not solve them.

One more consideration: sprint length interacts with release cadence but is not the same thing. A team on two-week sprints with Feature Flags and continuous deployment may ship 40 times per sprint. The sprint is an inspect-and-adapt rhythm, not a release schedule.

Scope Change Mid-Sprint

This is where sprint discipline is tested and where most teams quietly abandon it. The rules are more nuanced than “no changes allowed,” and understanding the nuance is what keeps the practice honest.

Who Owns What

Artifact	Owner	Can change mid-sprint?
Product Backlog	Product Owner	Yes, freely and continuously
Sprint Goal	Set collaboratively at planning	No — it is the sprint’s commitment
Sprint Backlog	The Developers	Yes — the Developers add, remove, and resplit items as they learn
Increment / Definition of Done	Team, org standards	Not mid-sprint

The critical and widely misunderstood point: the Sprint Backlog belongs to the Developers. They can and should modify it during the sprint. Discovering that an item needs a preliminary refactor, that two stories should merge, that an estimate was badly wrong — all of these lead to legitimate Sprint Backlog changes. What the Developers cannot do unilaterally is change the Sprint Goal, and what the Product Owner cannot do unilaterally is push new work into the Sprint Backlog.

New work enters mid-sprint only through negotiation between the Product Owner and the Developers, and it should not endanger the Sprint Goal. The healthy version of this conversation is a trade, not an addition: “we can take this in if we drop something of comparable size.”

The Honest Version

Real teams get genuine emergencies: a production outage, a security disclosure, a customer contract at risk. Pretending otherwise makes the framework brittle and encourages teams to lie about what they did. The workable approaches, in rough order of preference:

Plan for interruption. Teams with recurring unplanned work reserve capacity for it — commit to 70 or 80 percent of measured velocity and leave the rest as buffer. This is the most common and most effective answer. It is not cheating; it is planning against reality.
Swap like for like. A five-point emergency comes in, a five-point planned item goes back to the Product Backlog. The Sprint Goal survives, the timebox survives, and the tradeoff is explicit and recorded.
Accept the goal miss deliberately. Sometimes the emergency is genuinely more important than the goal. Say so out loud, note it, and discuss the pattern at the retrospective. A team that misses a goal once for a real outage is fine. A team that misses it every sprint has a structural problem — usually no separate support rotation, or a Product Owner who cannot say no.
Route around the sprint entirely. For teams whose work is dominated by unplannable interrupts — production support, platform on-call, infrastructure — the correct move is often not a better sprint but a different method. See the Kanban section below.

What does not work: silently absorbing extra work, keeping the original plan on paper, and then explaining the miss at review. That corrupts the data everyone is using to forecast and hides the real signal.

Sprint Cancellation

Almost nobody knows this exists, and it is a genuine part of the framework.

A sprint can be cancelled before its timebox ends, and only the Product Owner has the authority to do so. The Scrum Master and Developers can and should recommend it, but the decision is the Product Owner’s alone — it is a product decision, not a process one.

The sole legitimate reason is that the Sprint Goal has become obsolete. Not “we are behind,” not “the work turned out harder,” not “a stakeholder is unhappy.” Obsolete means the objective no longer makes sense: the market shifted, the company pivoted, the underlying assumption was disproved, a regulation landed, the feature was cut. If the goal is still worth pursuing, the answer is to reduce scope, not to cancel.

When a sprint is cancelled:

Any completed and Done items are reviewed and, if valuable, accepted and potentially released.
Incomplete items return to the Product Backlog and are re-estimated, since their value and context have likely changed.
The team goes straight into a new Sprint Planning and starts a new sprint. There is no gap and no “recovery week.”
Most teams should still hold the Retrospective. Understanding how a goal became obsolete mid-sprint is high-value information about planning horizon and refinement quality.

Cancellations should be rare — many teams go years without one. They consume the team’s time in re-planning and are disruptive by design. But their existence matters for a subtle reason: cancellation is the legitimate escape hatch, which means every other pressure to break the timebox has a proper answer. “Can we extend the sprint?” No. “Can we swap scope?” Yes, if the goal survives. “The goal is dead?” Then cancel and start fresh. There is no situation requiring a sprint to run long.

Why Kanban Teams Have No Sprints

Sprints are not a maturity milestone. Kanban teams that do not sprint are not doing a lesser version of agile — they are optimizing for a different constraint, and for certain kinds of work they are simply right.

Kanban replaces the timebox with work-in-progress limits as its core constraint. Where a sprint bounds time and lets scope flex, Kanban bounds concurrency and lets each item take the time it takes. Flow is continuous: an item is pulled when capacity frees up, not when a planning meeting happens. Forecasting comes from cycle time distributions and Monte Carlo simulation over historical data rather than from velocity across equal intervals — and for many teams that is a more accurate forecast, because it does not assume items are interchangeable in size.

Dimension	Sprint-based (Scrum)	Continuous flow (Kanban)
Core constraint	Fixed time; scope flexes	WIP limits; time per item flexes
Planning	Batched at sprint start	Just-in-time when capacity opens
Commitment	Sprint Goal for the timebox	No timebox commitment; service-level expectations instead
Forecasting basis	Velocity across equal intervals	Cycle time percentiles, Monte Carlo
Release cadence	Increment per sprint, or continuous	Continuous by default
Handles interruption	Poorly without reserved capacity	Natively — reprioritize the queue any time
Improvement cadence	Retrospective at fixed points	Continuous, plus flow metrics review

Kanban is the better fit when:

Work arrives unpredictably. Support, on-call, incident response, and platform teams cannot plan a two-week batch when half their week is reactive. Forcing a sprint onto that work produces missed goals every sprint and teaches everyone that goals are decorative.
Item sizes vary wildly. If work ranges from a one-hour config change to a three-week migration, batching into equal intervals adds nothing.
Priority genuinely changes weekly. A team serving many internal customers with shifting urgency gets more value from a reorderable queue than from a two-week freeze.
The team is already delivering continuously. A mature team shipping several times a day may find the sprint boundary an artificial ceremony wrapped around a flow they have already optimized.

Sprints are the better fit when the team needs a forcing function: a rhythm to make prioritization happen, a fixed point to gather stakeholder feedback, a regular protected block, or a cadence that lets the wider organization plan around it. Many teams run Scrumban — WIP limits and continuous flow inside the sprint, with the sprint retained purely as a review and retrospective cadence. That is a legitimate and common endpoint, not a compromise.

The wrong reason to drop sprints is that timeboxes feel uncomfortable. The right reason is that the nature of the work makes a fixed-scope-per-interval batch a poor model of how value actually flows.

Reading Sprint Health

A sprint generates signal whether or not anyone reads it. The useful signals are mostly about consistency and shape, not raw output — a single number in isolation says almost nothing.

Signal	Healthy pattern	Warning pattern	Usual root cause
Goal attainment	Met roughly 80 percent of sprints	Met every time, or almost never	Never missing means padded forecasts; always missing means overcommitment or unmanaged interrupts
Carryover	Zero to one item, occasionally	The same item rolls for three sprints	Items too large, or a dependency the team does not control
Burndown shape	Steady descent from early in the sprint	Flat then cliff on the last two days	Too much work in progress; everything finishing at once
Velocity variance	Within roughly 20 percent sprint to sprint	Swings of 2x	Inconsistent estimation, or wildly variable interrupt load
Unplanned work share	Under 15 percent, or explicitly reserved	40 percent and unacknowledged in planning	Missing support rotation; planning ignores known reality
Review attendance	Real stakeholders, real questions	Only the team, or a silent audience	The increment is not real enough to react to, or the wrong people are invited
Retro actions	One or two carried into the next Sprint Backlog	A growing list nobody starts	Improvements never allocated real capacity

Two derived measures are worth tracking beyond velocity. Say-do ratio — items forecast versus items Done — is a blunt instrument but exposes chronic overcommitment quickly. Cycle time within the sprint — how long an item takes from first commit to Done — is more diagnostic than velocity, because it reveals whether work flows or queues. A team with stable velocity but a cycle time creeping from two days to six is degrading, and velocity alone will not show it.

Resist turning any of these into a target. Every one of them can be gamed by an anxious team: velocity by inflating points, carryover by resplitting items at the end of the sprint, goal attainment by writing trivially achievable goals. They are instruments for the team’s own inspection, not a performance dashboard for management. The moment they become the latter, they stop measuring anything.

Comparison

Concept	What it is	Time boundary	Commitment	Relationship to Sprint
Sprint	Fixed-length container producing a releasable increment	Fixed timebox, 1 to 4 weeks, never extended	Sprint Goal	The unit itself
Iteration (generic)	Any repeated development cycle in Iterative and Incremental Development	Often fixed, but not required to be	Varies by method	A sprint is an iteration with Scrum’s specific events, roles, and goal requirement
Release	A version delivered to users	Any length; may span or subdivide sprints	Scope-based, usually	Orthogonal. A sprint may contain many releases or none
Milestone	A dated marker in a plan, often phase-gated	Fixed date, but scope usually fixed too	Both date and scope	The opposite tradeoff — milestones typically fix scope and let dates slip, or fix both and let quality slip
Kanban cycle	The time one item takes from start to done	No timebox; measured after the fact	Service-level expectation, not a goal	The flow-based alternative; see the section above

A useful distinction: a sprint fixes time and flexes scope. A Waterfall Model phase fixes scope and flexes time. A fixed-date, fixed-scope commitment fixes both and — since something must give — flexes quality, which is the one variable nobody agreed to trade.

Real-World Use Cases

A SaaS product team on two-week sprints with the goal “self-serve trial users can upgrade to paid without contacting sales.” Seven backlog items serve that outcome; two get cut mid-sprint when payment webhook handling proves harder than estimated, and the goal is still met.
A mobile team aligning sprints to app store review latency, using three-week sprints so that a submission made mid-sprint has cleared review before the Sprint Review, letting stakeholders see the shipped build rather than a simulator.
A platform team abandoning sprints for Kanban after tracking that 60 percent of its work arrived as unplanned interrupts from other teams. Goals were missed nine sprints running; switching to WIP limits and cycle-time SLAs made the same throughput legible and stopped the ritual of failing.
A regulated fintech team on two-week sprints with a hardened Definition of Done that includes an audit-log entry, a security review sign-off, and a completed change record — sized down deliberately because the “done” bar is expensive.
A startup on one-week sprints during pre-Product-Market Fit discovery, where each sprint tests one hypothesis with real users and the goal is stated as a question the sprint must answer.
A migration team using a sprint goal of “all read traffic for the orders service served from the new datastore behind a flag,” with rollout and cutover handled by Feature Flags independently of the sprint boundary.
A Product Owner cancelling a sprint on day four when a competitor acquisition made the integration being built pointless; two Done items were kept, the rest returned to the backlog, and a new sprint began the next morning.
A team reserving 25 percent capacity for production support after three consecutive sprints of missed goals traced to on-call load, planning to 22 points instead of 30 and hitting the goal five sprints in a row afterward.
An enterprise group running synchronized two-week sprints across eight teams under Scaled Agile (SAFe and LeSS), so cross-team dependencies land on a shared cadence rather than arriving at random.

Common Pitfalls

Extending the sprint to finish the work. The single most damaging habit. It destroys velocity comparability, dodges the prioritization decision, and teaches everyone the deadline is negotiable. Let the sprint end; carry the unfinished item over.
No Sprint Goal, or a goal that is just the backlog restated. “Complete the sprint backlog” is not a goal. Without a coherent objective, mid-sprint tradeoffs become impossible and the sprint reduces to ticket accounting.
Treating the forecast as a commitment. Sprint Planning produces a best estimate of what fits, not a contract. When leadership treats the forecast as a promise, teams respond by sandbagging estimates, and the numbers stop meaning anything within about three sprints.
Mini-waterfall inside the sprint. Analysis Monday to Tuesday, coding Wednesday to Thursday, testing crammed into Friday. This produces a cliff-shaped burndown, guaranteed carryover, and testing that is always the thing that gets cut.
Starting everything, finishing nothing. Nine items at 80 percent delivers zero value. Limit work in progress, swarm on the highest-priority item, and finish before starting. See Velocity and Burndown Charts for how this shows up in the data.
A weak or drifting Definition of Done. “Done except for testing” and “done pending deployment” build an invisible queue of unverified work and inflate velocity. Undone work compounds; by sprint six the team is drowning in an integration debt nobody logged.
The Product Owner injecting work mid-sprint without a trade. Additions must be negotiated and should not endanger the goal. When they arrive unilaterally and repeatedly, the sprint boundary stops protecting anything and the team stops planning seriously.
Skipping the retrospective when things are busy. The retro is the only mechanism the team has for fixing the reasons it is busy. Cutting it when under pressure is precisely backwards, and the improvement debt compounds like Code Refactoring and Technical Debt.
Padding estimates to guarantee a hit. Consistently finishing early with slack left over is not success; it means the forecast has stopped being informative. Aim for goals met roughly 80 percent of the time — a team that never misses is not planning ambitiously enough to learn anything.
Changing sprint length to solve a delivery problem. If nothing finishes in two weeks, the causes are item size, WIP, or a slow Definition of Done gate. A longer sprint conceals all three.

Scrum — the framework that defines the sprint, its events, artifacts, and accountabilities
Product Backlog and Refinement — the ordered source of work that feeds Sprint Planning; refinement quality determines planning quality
Definition of Done — the shared quality bar that decides whether sprint work actually counts as complete
Velocity and Burndown Charts — the measurements that only work because sprints are equal-length timeboxes
Sprint Retrospective — the closing event that inspects and adapts the team’s process
Story Points and Estimation — how items are sized so a sprint’s capacity can be forecast
Kanban — the flow-based alternative that replaces the timebox with work-in-progress limits
Agile Manifesto — the underlying values that make short feedback cycles preferable to long plans

Example

A six-person team at a logistics SaaS company runs two-week sprints starting Wednesday. Their Product Owner opens Sprint Planning with a proposed goal: “A dispatcher can reassign a driver mid-route and the driver’s app reflects it within ten seconds.” Support has escalated this repeatedly — dispatchers currently cancel and recreate routes, which loses the delivery history. The team refines the phrasing, agrees the outcome is testable, and pulls seven backlog items totaling 26 points against a trailing three-sprint average of 31, holding back capacity for the on-call rotation. During the “how” discussion, two developers disagree about whether reassignment should push through the existing WebSocket channel or a new one; twenty minutes of argument at the whiteboard settles on reusing the channel and saves what would have been three days of divergent work.

Day four brings trouble. The driver app’s local state cache turns out to assume routes are immutable — an assumption baked into six screens. The five-point story balloons to something closer to thirteen. At the Daily Scrum the team asks the only question that matters: does the goal survive if we cut something? They decide it does. Two items — a dispatcher audit-log view and a settings toggle for notification sound — go back to the Product Backlog, and the Product Owner agrees without much debate because neither serves the goal. On day seven a genuine emergency lands: a customer’s nightly export job is producing corrupt CSVs. One developer takes it out of the reserved on-call capacity, it costs a day and a half, and the plan absorbs it. The Sprint Backlog at day eight looks meaningfully different from the plan made on day one, and the goal has not moved an inch.

They finish on the Tuesday afternoon before review. Reassignment works, propagating in about four seconds under load; five of the original seven items are Done, two are not, and the goal is met. At the Sprint Review, a dispatcher from the pilot customer watches the demo and asks whether reassignment can be undone within a minute — nobody had considered it, and it becomes the top backlog item for the next sprint. The retrospective focuses on the immutability assumption: nobody had known the cache made it, and the item had passed refinement looking simple. The team’s one improvement for the next sprint is a fifteen-minute technical spike during refinement for any story touching the driver app’s state layer, added to the next Sprint Backlog as a real item so it competes for real capacity. The sprint ends. The next one starts Wednesday morning.

Referenced by

Dig deeper

Spot an error in this note?