The engineering sprint planning decision record: why the sprint planning model you chose determines your delivery predictability ceiling and your scope creep surface

A 13-person developer tools startup had been running without a formal sprint planning process since its founding. The engineering team operated on a shared Notion backlog; each morning the engineers pulled what they were working on from the backlog, chose tasks based on the current priority signals from Slack and their own judgment about what needed to get done, and updated the backlog's status column as they moved through work. The CTO considered this model a deliberate choice — "agile without the ceremony" — and pointed to the team's ability to ship features quickly as evidence that the model worked. The team was genuinely productive. Features moved from idea to production quickly. Customer feedback was incorporated rapidly. The absence of sprint planning meetings was perceived as a competitive advantage over slower-moving companies running two-day quarterly planning sessions.

In month seven, two engineers independently began working on adjacent features whose combination produced a user experience conflict neither had identified because neither had maintained a shared artifact of what was committed in the current cycle. One engineer was building a notification preferences panel; the other was building a notification digest feature that assumed all notification types were enabled by default. The conflict was discovered at code review. It required two additional days of coordination to resolve. It was considered a minor incident — a coordination miss that could happen to any team. The CTO filed it under "we should probably communicate more."

In week twelve of the same period, two engineers began a subscription payment flow refactor — a three-week piece of work that required migrating from one payment processor SDK to another. At week fourteen, one of the two engineers was pulled onto a customer escalation that required his full attention for the following six days. The other engineer continued on the refactor alone. At week sixteen, the second engineer was reassigned to a priority feature for the upcoming product launch. The refactor was approximately 60% complete: the new SDK integration was done, three of eight payment flow tests had been updated to the new interface, and five remained on the old interface. The sprint board — which was the Notion backlog — showed the refactor as "In Progress." There was no mechanism to flag that a 60%-complete critical-path item had lost both of its assigned engineers and had no owner for completion. No one picked it back up. By month ten, the item had been in "In Progress" for eight weeks, neither of the original engineers had context on the incomplete integration tests, and the payment flow was running on a partial migration that two engineers in a future session would spend a week untangling before concluding that the simplest path was to revert and start the migration fresh from a clean state.

When the company began its Series A fundraise in month eleven, the lead investor asked for a sprint velocity summary and a breakdown of delivery across infrastructure, security, and feature work over the prior two quarters. The CTO built the summary retrospectively from the git commit log. The finding was that the team had shipped features in nine of eleven two-week rolling windows but had delivered zero measurable infrastructure or security work in the same period — not because the engineers were ignoring those items, three of which had appeared in the backlog for the full eleven cycles, but because the planning model had no mechanism to claim and protect capacity for non-feature work. Each morning's task-selection process resolved in favor of the most visible work, and the most visible work was always a customer-facing feature. The three infrastructure items — an overdue dependency audit, a database index review that the founding engineer had flagged as "needs doing before we scale," and a background job error handling improvement — had been in the backlog for eleven cycles and had each lost eleven consecutive daily prioritization arguments to feature work that was more visible and more immediately consequential. None of the three items had generated an escalation signal. The backlog had no mechanism to surface that an item had been in "not started" status for eleven cycles without a date or owner, which was the difference between a deliberately deprioritized item and an item that had fallen through the planning model's cracks.

A 43-person B2B SaaS ran story-point-based sprint planning with a planning meeting at the start of each two-week sprint, committed sprint scope, sprint retrospectives at the sprint close, and velocity tracking that charted story points completed per sprint for each of the company's three engineering teams. The model had been in place for eighteen months. Sprint completion rates averaged 91% across all three teams — the fraction of committed story points delivered in the sprint in which they were committed. The sprint retrospective scores averaged 4.4 out of 5 for "our sprints feel productive and well-planned." The VP of Engineering reviewed velocity charts quarterly and considered the sprint process one of the company's execution strengths. When a Series B investor asked about engineering execution quality in the due diligence process, the velocity chart and sprint completion rate were the primary evidence presented.

At the Q2 account review, the customer success team presented a renewal risk analysis for the company's thirty-seven enterprise accounts. Three accounts at renewal — collectively representing $340k ARR — had each cited in their most recent QBRs a specific integration gap: Salesforce data sync for event attribution, which the account teams needed to connect product usage data to their marketing attribution models. The integration had been in the product backlog for seven months. It had been labeled P2 in each of fifteen consecutive sprint planning sessions. In each session, it had lost the prioritization argument to P1 features with committed sprint deliverables, customer escalations, and performance improvements that had clearer near-term impact on more accounts than the three accounts the Salesforce integration would serve. Each individual prioritization decision had been defensible. The aggregate outcome — fifteen consecutive sprints without addressing an item that represented a renewal risk for accounts generating $340k ARR — was visible only in retrospect, when two of the three accounts declined to renew and cited the same gap in their exit surveys.

The post-churn retrospective identified the structural failure: the sprint planning model evaluated each sprint's backlog from scratch, without any mechanism to surface that a backlog item had been deprioritized for fifteen consecutive sprints. The P2 label on the Salesforce integration item was assigned in each sprint planning session based on the same analysis — "this would help three enterprise accounts but we have higher-priority work for more accounts" — and was correct in isolation for each sprint. The analysis that would have changed the outcome was not "is this item higher priority than these other items?" but "has this item been in the P2 category for fifteen sprints, and what is the cumulative cost of continued deprioritization relative to the cumulative cost of the alternative items we have been prioritizing?" The backlog had no field for consecutive sprint age. The sprint planning meeting had no standing agenda item that asked "which items have been in this backlog the longest without being addressed, and is the reason they have not been addressed still valid?" The model's velocity charts and sprint completion rates measured the team's execution speed and consistency. Neither metric captured whether the team was executing against the right backlog items — the items whose continued deprioritization was accumulating into a business risk that would not be visible until a renewal conversation.

The two churned accounts were replaced by two new accounts at a higher contract value within two quarters, and the Salesforce integration shipped in Q3. The VP of Engineering considered the incident a prioritization failure — the team had made the wrong call on the Salesforce item. The more accurate diagnosis was a planning model failure: the team had made fifteen locally defensible prioritization calls and accumulated a business consequence that none of the fifteen individual calls had produced a signal for, because the planning model had no mechanism for local decisions to aggregate into a visibility signal before the business consequence arrived.

A 74-person enterprise SaaS with seven product teams ran a mature sprint planning process that had been refined over three years: story points, sprint goals written at the sprint outcome level rather than the task level, sprint retrospectives with structured follow-through, quarterly velocity reviews, and program increment planning sessions every ten weeks in which all seven teams committed their sprint scope six weeks out and identified cross-team dependencies. The PI planning model had been designed with a 60/40 committed-to-flexible split — 60% of each team's sprint capacity was committed to specific deliverables in the PI planning session, and 40% was reserved as flexible capacity to absorb platform dependencies, emerging customer priorities, and the mid-sprint scope discoveries that the PI planning session's six-week horizon could not anticipate. The VP of Engineering had explicitly designed the 40% flexible capacity buffer as a protection against the overcommitment patterns the company had experienced under a previous fully-committed planning model. The buffer was considered a core design principle of the current model.

At the annual planning retrospective at the end of Q3, the VP of Engineering reviewed sprint execution data across all seven teams for the prior three quarters. The analysis found that the actual committed capacity averaged 94% across all teams — not the 60% the PI planning model specified. The 40% flexible capacity buffer had eroded to an effective 6% across all seven teams over nine months, without any team, any product manager, or any PI planning session having explicitly decided to change the buffer policy. The erosion had happened through the sprint planning conversations that occurred each week: in the moment of sprint planning, the sprint board showed unassigned capacity, and each unassigned capacity slot was an implicit question — "why isn't this customer-requested feature in this sprint if there's capacity?" The product managers, whose roadmap commitments to customers were tracked at the quarterly level, had no incentive to defend anonymous buffer against a specific customer-requested task they could name and point to. Over nine months, in sprint after sprint across all seven teams, specific tasks had been placed into the buffer slots until the buffer was structurally committed in the first thirty minutes of every sprint planning meeting.

The 94% committed capacity meant that every mid-sprint scope addition — platform dependency changes, production incidents, emerging customer priorities — was absorbed by displacing committed scope to the next sprint rather than by consuming flexible capacity. The teams were not experiencing this as scope creep; they were experiencing it as normal sprint execution, because the sprint planning model's metric was sprint completion rate — the fraction of committed scope delivered in the sprint in which it was committed — and the teams were achieving 92% sprint completion by moving buffer-designated items to "next sprint" at the mid-sprint scope adjustment conversations rather than by protecting buffer as an execution constraint. A team whose sprint board has 94% committed capacity and 6% flexible capacity is a team that has been fully committed since sprint planning, and whose sprint completion rate is maintained by identifying, mid-sprint, which 6% of committed items can be displaced to the next sprint without triggering an escalation. The sprint completion rate appeared healthy. The metric that would have revealed the buffer erosion — the fraction of items initially placed in the flexible capacity slot that were completed within two sprints of the sprint in which they were designated — was not being tracked. The VP of Engineering had designed the buffer policy and the sprint health review without including a metric that could detect whether the buffer was functioning as designed or had eroded to nominal.

When the analysis revealed the 94% actual committed capacity, the VP of Engineering asked the seven team product managers and engineering managers to explain how the buffer had eroded. The answers were consistent across all seven teams: the buffer was visible in the sprint board as unassigned capacity, unassigned capacity in a sprint board looks like available capacity to anyone who has a task to place, and product managers consistently placed tasks into the buffer because the alternative — defending anonymous buffer against a specific customer-requested task — required explaining why capacity that appeared to be available was not available, which is a harder conversation than placing the task in the available slot. The buffer policy had been designed as a planning principle. It had not been implemented as a planning constraint. The difference was that a constraint limits what can be placed in the buffer slots; a principle describes the buffer's intended purpose and relies on participants to honor it. The seven teams had been honoring the principle by intention and eroding it in practice, without any participant having made a deliberate decision to change the policy.

Structural properties set by the engineering sprint planning decision

Two structural properties are determined by the founding decisions about scope commitment, backlog management, buffer architecture, and sprint health measurement. Both are invisible when the team is small enough that informal daily coordination provides visibility into competing priorities and in-progress work; both become visible when informal coordination no longer covers the full set of commitments the team is managing, when the first investor due diligence reveals that sprint velocity is high and investment category balance is zero, and when the first renewal conversation reveals that the team's planning model's health metrics were measuring the wrong things.

Property 1: Delivery predictability ceiling. The delivery predictability ceiling is the degree of confidence stakeholders can have in the team's delivery timeline for a committed scope, bounded by three factors. First, scope commitment model: whether the team's sprint commitment creates friction when scope changes mid-sprint or records the team's intent without enforcing it. The first failure story illustrates the commitment absence failure mode: a planning model with no commitment artifact produces a team whose delivery timeline is predictable only in the aggregate — the team will ship features at approximately its current velocity — and unpredictable at the item level, because any item can be displaced by any competing priority without acknowledgment. A team with no sprint commitment is not an uncommitted team; it is a team whose commitments are made and revised implicitly, through daily task selection and priority conversations, without the visibility that would allow stakeholders to predict what will be delivered by a specific date. Connect this to the engineering technical roadmap communication decision record: the roadmap communication model and the sprint planning model are coupled at the commitment layer — a roadmap that communicates customer-facing deliverables with quarterly precision requires a sprint planning model that makes and maintains sprint-level commitments that add up to the quarterly deliverable, and a sprint planning model that has no commitment mechanism produces a roadmap whose confidence tier is determined by the team's velocity rather than by its ability to commit to and deliver specific items in a specific sequence. Second, backlog visibility model: whether the planning model surfaces which items have been consistently deprioritized so that the cumulative cost of continued deprioritization is visible before the business consequence arrives. The second failure story illustrates the backlog blindness failure mode: a sprint planning model that evaluates each sprint's backlog from scratch treats fifteen consecutive deprioritizations of the same item as fifteen independent decisions rather than as a pattern requiring a different evaluation frame. The evaluation frame that would have changed the outcome — "this item has been in this backlog for fifteen sprints; what is the cumulative cost of continued deprioritization relative to the sprint-level value of the items that have displaced it?" — is not available in a sprint planning model that has no mechanism for item age in the backlog. Connect this to the engineering metrics decision record: backlog age distribution — the fraction of backlog items by age bucket (0–2 sprints, 3–6 sprints, 7+ sprints) — is a leading indicator of delivery predictability failure, because items that have been in the backlog for seven or more sprints without being addressed represent either a prioritization model that consistently fails to reach important work or a backlog hygiene failure that keeps items in the queue after they have been superseded or invalidated; both conditions reduce delivery predictability for the work that the team will eventually need to do. Third, incomplete work tracking model: whether work that spans sprint boundaries has explicit re-commitment in the next sprint's planning or falls into an ambiguous status where no sprint owns its completion. The first failure story's 60%-complete subscription refactor illustrates the incomplete work visibility failure mode: a planning model that does not require incomplete items to be explicitly re-committed in the next sprint's planning creates a category of work that the sprint board shows as "In Progress" and no sprint claims as committed — work that is simultaneously being tracked and not being owned, in a status that generates no escalation signal regardless of how long it remains incomplete. Connect this to the engineering documentation standards decision record: incomplete work whose status is "In Progress" without an owner and a sprint commitment is the planning equivalent of an architecture decision record that records the decision made without recording the constraints that make it correct — the artifact exists, the information it should contain is absent, and the absence is not visible from the artifact's presence in the system.

Property 2: Scope creep surface. The scope creep surface is the fraction of sprint capacity absorbed by work not committed at the start of the sprint, and the cumulative erosion of the team's ability to deliver on commitments that scope creep produces over time, determined by three factors. First, buffer enforcement model: whether the sprint model's designated flexible capacity is enforced as a planning constraint or erodes under prioritization pressure. The third failure story illustrates the buffer erosion failure mode: a buffer that is defined as a planning principle and implemented as unassigned capacity in the sprint board is a buffer that evaporates in every sprint planning conversation, because unassigned capacity is visually indistinguishable from available capacity and the planning conversation's incentives consistently resolve in favor of placing a named task in a visible capacity slot. The buffer erosion failure mode is particularly difficult to detect because it produces a healthy sprint completion rate — teams with eroded buffers achieve high sprint completion rates by identifying which committed items to displace when mid-sprint scope additions arrive, which is a sprint completion optimization that is indistinguishable from genuine delivery reliability in a metric that measures committed scope completion rather than the gap between committed scope and original planning intent. Connect this to the engineering metrics decision record: the sprint health metrics that reveal buffer erosion are distinct from the sprint metrics that reveal velocity — buffer effectiveness rate (the fraction of items placed in the flexible capacity slot completed within two sprints of their designation), mid-sprint scope addition rate (the number of items added to committed scope after sprint planning per sprint), and nominal-to-actual buffer gap (the difference between the buffer percentage specified in the planning policy and the buffer percentage implemented in the sprint board at the start of each sprint); none of these metrics are produced by the standard sprint planning model's measurement set, and all three are required to distinguish a sprint model that is functioning as designed from a sprint model that is producing sprint completion rates by silently eroding the design properties that the planning model was built to enforce. Second, mid-sprint change protocol: the explicit criteria and cost required to modify committed scope after the sprint begins. A mid-sprint change protocol that is undefined produces a planning model where the sprint's committed scope is a planning artifact rather than a delivery constraint — the commitment is real at planning time and erodes in real time as mid-sprint priorities are added, each by a local decision that is individually defensible and collectively produces a sprint whose delivered scope is predictable neither by the original plan nor by any revision of it. The key property of a functioning mid-sprint change protocol is not that scope changes are prevented — mid-sprint scope additions are sometimes the right decision — but that each change requires the team to identify what is being displaced, confirm that the trade-off is correct, and log the displacement as a planning record, so that the cumulative pattern of mid-sprint changes is visible at the sprint retrospective and in the planning health review. Connect this to the engineering technical strategy decision record: mid-sprint scope changes that consistently displace infrastructure and technical debt items represent a pattern where the sprint's commitment mechanism is functioning correctly for feature work and failing for non-feature work — the commitment holds for items whose stakeholders are present in the mid-sprint scope change conversation and erodes for items whose stakeholders are either absent or less able to defend their priority against a competing feature claim. Third, investment category representation: whether the sprint planning model has named, defended capacity for non-feature work. The first failure story illustrates the investment category failure mode: a planning model that does not allocate capacity to infrastructure, security, and technical debt before the feature prioritization conversation begins produces eleven consecutive sprints with zero non-feature delivery — not because the team is neglecting non-feature work, but because every sprint planning conversation's incentive structure resolves in favor of work whose impact is visible to the stakeholders in the room, and non-feature work's impact is invisible in the short run to exactly the stakeholders who are present and whose priorities drive the planning outcome. Connect this to the engineering technical strategy decision record: a technical strategy that specifies the team's infrastructure investment targets — the fraction of engineering capacity allocated to technical debt reduction, security maintenance, and infrastructure reliability over the planning horizon — requires a sprint planning model that implements those targets as capacity allocations rather than as aspirations, because a strategy that specifies investment targets but routes all capacity through the same prioritization conversation as feature work will produce investment targets that are met in the quarters where no high-priority feature work competes for the same capacity and missed in every other quarter.

The engineering sprint planning ADR: five sections

Section 1: Sprint scope commitment model and change friction. The scope commitment model defines what constitutes a sprint commitment, how the commitment is recorded, and what the mechanism is for mid-sprint scope changes. Three components. Commitment definition: a sprint commitment is not a list of tasks the team intends to complete; it is a set of items whose completion within the sprint the team is willing to have stakeholders plan against. The distinction determines what appears in the committed sprint scope: items whose completion is predictable given the team's current context, whose dependencies have been resolved, and whose scope is understood well enough to estimate — not items that might be completed if no competing priorities arrive, not items that have been in the backlog for three cycles and need to be cleared out, and not items that require a dependency that the planning conversation has flagged as uncertain. The commitment definition should produce a committed sprint scope that the team can deliver without scope changes at a rate the team is willing to cite as its sprint commitment completion rate. Commitment record: the sprint board's committed scope column is the commitment record — the items in the committed column at the start of the sprint are the commitments, and any item moved into or out of the committed column after sprint planning is a scope change requiring the change friction protocol. The commitment record should be a team artifact, not a process artifact: it is updated by the team as scope changes occur, not by a separate process. Change friction protocol: when a competing priority arrives mid-sprint and a scope change is considered, the protocol requires three actions before the change is confirmed — name the item being displaced (the specific committed item that will not be completed in this sprint if the scope addition is accepted), confirm that the competing priority is higher-value than the displaced commitment (a one-sentence acknowledgment by the stakeholder requesting the addition, written into the sprint board record), and assign the displaced item to the next sprint's committed scope in the same step (not to the general backlog, where it will re-enter the prioritization queue — to the next sprint's committed column, with the same priority it held in the current sprint). The three-action protocol produces a scope change record that is visible at the sprint retrospective, and the assignment of the displaced item to the next sprint's committed scope prevents the first failure story's "In Progress" limbo — the state where a mid-sprint deprioritization produces an item that is neither completed nor re-committed and whose status generates no escalation signal.

Section 2: Sprint goal quality and backlog visibility model. The sprint goal model defines what a sprint goal is, how it is written, and how the backlog surfacing model ensures that consistently deprioritized items generate an escalation signal before the business consequence of continued deprioritization arrives. Three components. Sprint goal quality criteria: a sprint goal is a statement of the outcome the team will demonstrate at the sprint review, not a list of tasks the team will complete. A sprint goal written at the task level — "complete the notification preferences panel, migrate two API endpoints to the new SDK, fix three customer-reported bugs" — describes what the team plans to do without specifying the value the work produces; a sprint goal written at the outcome level — "customers can configure their notification preferences for the first time, reducing notification-related support volume by our expected rate" — describes the value the work produces and creates a shared evaluation criterion for the sprint retrospective. The sprint goal quality criterion is not a semantic preference; it is a planning calibration mechanism: a team that writes sprint goals at the outcome level is forced to have the conversation about which tasks are required to produce the stated outcome, which is the conversation that surfaces task dependencies, scope discoveries, and competing priority claims before the sprint begins rather than after. Backlog age surfacing: the backlog grooming meeting includes a standing review of items in the "not started" or "P2" category that have been in the backlog for more than four sprints. For each item in the four-sprint-plus age category, the review asks two questions: is the reason this item has been deprioritized four or more times still valid? and what is the cumulative cost of one additional sprint of deprioritization relative to the cost of the items currently above it in priority? The standing review does not require that long-tenured items be promoted; it requires that their continued deprioritization be a deliberate decision rather than an outcome of a prioritization conversation that did not include their age as an input. Items whose age exceeds eight sprints generate an automatic escalation to a named stakeholder — the product manager and engineering manager jointly — who must either promote the item into the next sprint's committed scope or close the item with a documented reason. The escalation threshold and resolution requirement convert the second failure story's pattern — fifteen consecutive defensible deprioritizations that accumulated into a renewal risk — into a process that surfaces the pattern at the eight-sprint mark rather than at the renewal conversation. Incomplete work ownership: any item that is committed in a sprint and not completed in that sprint is transferred to the next sprint's committed column automatically, not to the backlog. The transfer is an ownership transfer, not a deprioritization — the item retains its priority and enters the next sprint's planning as a carry-over commitment, not as a new backlog item competing for a planning slot. The carry-over status is visible in the sprint board and in the velocity calculation: carry-over items are excluded from the sprint's story point completion count (they were committed in a prior sprint, not in the current sprint), which means a team with carry-over items shows a lower effective velocity than its story point completion rate suggests, accurately reflecting the planning cost of the incomplete work.

Section 3: Buffer architecture and investment category model. The buffer model defines the fraction of sprint capacity held as flexible, how the buffer is implemented in the sprint board to prevent erosion, and how the investment category model ensures that infrastructure, security, and technical debt have named, defended capacity. Three components. Buffer size calibration: the buffer fraction is calibrated to the team's actual unplanned work absorption over the trailing six sprints — the fraction of each sprint's capacity consumed by work that was not in the committed scope at the start of the sprint. Teams that have not measured their unplanned work fraction should begin with 20% and adjust based on measured data; teams operating in high-interrupt environments (heavy production on-call, heavy customer escalation volume, active platform dependency exposure) typically require 25–35% flexible capacity to avoid structural overcommitment. Buffer implementation: flexible capacity is implemented in the sprint board as a named capacity reservation — "flexible: X points" — not as a list of named tasks assigned to specific engineers. The reservation is visible in the sprint board and is updated at each mid-sprint scope addition: when an unplanned task is absorbed into the sprint, the flexible capacity reservation decreases by the absorbed task's point value. If the flexible reservation reaches zero before mid-sprint, the next scope addition triggers the change friction protocol from Section 1 — a named displacement and stakeholder acknowledgment — rather than being absorbed silently into extended work hours or displaced committed scope. The buffer-as-reservation implementation makes the buffer erosion failure mode visible: in sprint planning, the product manager cannot place a task into the buffer because the buffer has no capacity slots to fill — it is a point reservation, not a task list. Investment category allocation: 20% of sprint capacity — in addition to the buffer reservation — is pre-committed to non-feature work before the feature prioritization conversation in sprint planning begins. The allocation is not negotiated in sprint planning; it is a planning constraint. The only planning conversation for the 20% non-feature allocation is which non-feature items are highest priority — not whether non-feature work gets capacity. The pre-committed allocation eliminates the unequal competition between feature work and non-feature work by removing non-feature work from the competition entirely. The 20% target is calibrated quarterly against the team's technical debt accumulation rate and infrastructure reliability metrics: if the quarterly technical debt review shows an accumulation rate that the 20% allocation is not covering, the allocation is increased; if the infrastructure reliability metrics show that the allocation is producing more maintenance capacity than the system requires, the allocation is decreased.

Section 4: Mid-sprint change protocol and scope governance. The mid-sprint change protocol defines the criteria and process for modifying committed sprint scope after the sprint begins, the stakeholder ownership model for scope change authorization, and the pattern tracking that connects individual scope changes to sprint health trends. Three components. Change authorization model: mid-sprint scope changes are authorized by the person whose commitment is being displaced — the engineering manager or technical lead who made the original sprint commitment — not by the person requesting the addition. The authorization model ensures that scope changes are evaluated from the perspective of the commitment being changed, not from the perspective of the competing priority being added. The authorizing stakeholder reviews the displacement trade-off — the item being displaced, the reason for displacement, the competing priority's urgency — and approves or declines. A decline does not mean the competing priority is unimportant; it means the competing priority is not more important than the displaced commitment and should be addressed by pulling it from the buffer reservation or by scheduling it in the next sprint's planning. Change documentation: each approved mid-sprint scope change produces a one-line record in the sprint retrospective log: the item added, the item displaced, the reason, and the stakeholder who authorized the trade-off. The documentation serves two purposes — it makes the trade-off visible at the sprint retrospective, allowing the team to evaluate whether the change was correct in retrospect, and it populates the pattern tracking input for the sprint health review. Pattern tracking: the sprint health review includes a quarterly analysis of mid-sprint scope change patterns across all teams — the most common sources of mid-sprint scope additions (production incidents, platform dependency changes, customer escalations, stakeholder-requested additions), the most common categories of displaced scope (infrastructure items, specific feature categories, specific team's work), and the correlation between mid-sprint scope addition frequency and sprint goal achievement rate. The pattern analysis produces an input to the sprint planning model's calibration: if mid-sprint scope additions are consistently driven by production incidents, the buffer reservation is too small or the on-call model is absorbing scope that should be absorbed by the on-call rotation; if displaced scope is consistently from the same category, the investment category allocation is too small for that category or the commitment model is not protecting it from mid-sprint displacement.

Section 5: Sprint health measurement and improvement cadence. The sprint health measurement model defines which metrics reveal whether the planning model is functioning as designed at the layer where delivery predictability is set — commitment mechanism and buffer enforcement — and the improvement cadence that connects measurement to planning model evolution. Three components. Health metric set: the sprint health metrics that reveal planning model function are distinct from the sprint metrics that reveal delivery velocity. Delivery velocity metrics — story points completed per sprint, sprint completion rate, feature throughput — measure the team's execution speed and consistency. Planning model health metrics measure whether the planning model's design properties are functioning as designed: buffer effectiveness rate (the fraction of items placed in the flexible capacity reservation that are completed within two sprints of their designation — a rate below 70% indicates that buffer items are consistently displaced, which is a signal that the buffer is absorbing committed-scope displacement rather than unplanned work absorption); backlog age distribution (the fraction of backlog items by age bucket — 0–2 sprints, 3–6 sprints, 7+ sprints — the 7-sprint-plus bucket is the leading indicator of the second failure story's pattern); nominal-to-actual buffer gap (the difference between the buffer percentage in the planning policy and the buffer percentage remaining at the start of each sprint's first day, which is the metric that would have revealed the third failure story's buffer erosion); and investment category balance (the fraction of delivered story points per sprint in each investment category — feature, infrastructure, security, technical debt — over a rolling twelve-week window). Measurement cadence: the delivery velocity metrics are reviewed at each sprint retrospective. The planning model health metrics are reviewed quarterly, using the trailing twelve weeks of sprint data, and the quarterly review produces a planning model calibration decision — the buffer size, investment category allocation, backlog age escalation threshold, and change friction protocol are each reviewed against the health metrics and adjusted where the metrics indicate the design property is not functioning. Connect this to the engineering metrics decision record: the sprint health metrics require a measurement model that distinguishes between metrics that measure whether the planning model is working and metrics that measure whether the team is executing quickly — a team that uses only delivery velocity metrics to evaluate sprint planning health is a team that can maintain high delivery velocity while systematically eroding buffer, accumulating backlog debt in the 7-sprint-plus age bucket, and delivering zero investment in infrastructure and technical debt, and whose planning health review will not detect any of these conditions until the velocity-invisible consequences arrive. Improvement protocol: when a health metric falls below its threshold — buffer effectiveness rate below 70%, backlog age distribution shows more than 15% of items in the 7-sprint-plus bucket, nominal-to-actual buffer gap exceeds five percentage points, investment category balance shows zero non-feature delivery in a rolling twelve-week window — the quarterly review produces a named root cause analysis and a named planning model adjustment, not a team-behavior coaching conversation. The adjustment is to the planning model's design — the buffer implementation mechanism, the backlog age escalation threshold, the investment category pre-commitment, the change friction protocol — rather than to the team's behavior, because the planning model's health metric failures are structural rather than behavioral: they indicate that a design property is not functioning as intended rather than that the team is executing against the design incorrectly. Connect this to the feature prioritization framework decision record: the sprint planning model is the execution layer of the prioritization framework — the prioritization framework decides which items are most valuable, and the sprint planning model decides how capacity is allocated to those items and how commitments are made and maintained; a sprint planning model's health metrics that show systematic underdelivery in a specific investment category are a signal that either the prioritization framework has not assigned those items enough priority to win the planning competition or the sprint planning model's capacity allocation mechanism is not implementing the prioritization framework's intent, and the distinction between the two root causes determines whether the fix is to the prioritization criteria or to the planning model's implementation.

FAQ

Further reading

• Engineering technical roadmap communication decision record — the roadmap communication model and the sprint planning model are coupled at the commitment layer: a roadmap that communicates customer-facing deliverables with quarterly precision requires a sprint planning model that makes and maintains sprint-level commitments that add up to the quarterly deliverable, and a sprint planning model that has no commitment mechanism produces a roadmap whose confidence tier is determined by the team's velocity rather than by its ability to commit to and deliver specific items in a specific sequence.
• Feature prioritization framework decision record — the sprint planning model is the execution layer of the prioritization framework: the framework decides which items are most valuable, and the sprint planning model decides how capacity is allocated to those items and how commitments are made and maintained; a sprint planning model's health metrics that show systematic underdelivery in a specific investment category are a signal that either the prioritization framework has not assigned those items sufficient priority or the sprint planning model's capacity allocation mechanism is not implementing the prioritization framework's intent.
• Engineering metrics decision record — the sprint health metrics that reveal planning model function are distinct from the sprint metrics that reveal delivery velocity; a team that uses only delivery velocity metrics to evaluate sprint planning health can maintain high delivery velocity while systematically eroding buffer, accumulating backlog debt, and delivering zero investment in infrastructure and technical debt — conditions that are invisible to the velocity measurement and visible only in the planning model health metrics that the standard sprint process does not produce.
• Engineering technical strategy decision record — a technical strategy that specifies infrastructure investment targets requires a sprint planning model that implements those targets as capacity allocations rather than as aspirations, because a strategy that specifies investment targets but routes all capacity through the same prioritization conversation as feature work will produce investment targets that are met in the quarters where no high-priority feature work competes for the same capacity and missed in every other quarter.
• Engineering documentation standards decision record — incomplete work whose sprint status is "In Progress" without an owner and a re-commitment is the planning equivalent of an architecture decision record that records the decision made without recording the constraints that make it correct: the artifact exists, the information it should contain is absent, and the absence is not visible from the artifact's presence in the system.
• Open-source extractor — the reasoning behind sprint planning decisions — why the buffer is enforced as anonymous capacity rather than named tasks, why non-feature work has pre-committed capacity rather than competing in the same prioritization conversation as feature work, what the backlog age escalation threshold was and how it was calibrated, why the sprint health metrics include investment category balance rather than only sprint completion rate — is reasoning conducted in AI chat sessions that does not survive into the sprint planning meeting agenda or the story point scale; running those sessions through the extractor produces the sprint planning decision record that allows the next engineering leader to inherit the reasoning rather than inheriting only the process and discovering its rationale by asking the engineering leader who designed it.