The sprint planning format decision record: why the capacity allocation model you chose determines your sprint commitment accuracy and your mid-sprint scope disruption rate

A 29-person healthcare analytics company built a B2B SaaS platform that aggregated clinical workflow data from hospital EHR integrations and produced operational reports for hospital administrators — bed utilization trends, nursing staff scheduling recommendations, readmission risk signals. The engineering team had eight engineers on the product team, two on the integration infrastructure team, and a shared QA engineer. The company ran two-week sprints. Sprint planning happened every other Monday from 9am to noon. The process was: the product manager walked through the backlog, engineers discussed and estimated stories in story points using a 1–2–3–5–8 scale, stories were pulled into the sprint until the point total reached the team's average velocity from the prior three sprints. That target velocity was recalculated each sprint. At the start of the third sprint, average velocity was 42 points. The team committed to 42 points and delivered 26. At the start of the fourth sprint, average velocity was 38 points. The team committed to 38 and delivered 20. The velocity-as-planning-target model was recalculating based on delivered points, which were themselves the product of the over-commitment — average velocity was chasing actual delivery downward without anyone understanding why.

At the end of the first year, the VP Engineering ran an analysis. The team had run 25 sprints. Average sprint completion rate: 58%. In 7 of 25 sprints, the team had delivered more than 70% of committed points. In 11 of 25 sprints, they had delivered less than 50%. The sprint completion failures were distributed across all engineers and all story types — they were not concentrated in particularly complex stories, in particular engineers, or in particular product areas. The failure pattern was systematic and uniform, which meant it was caused by the planning model, not by execution.

The VP Engineering spent two days auditing time distribution for four engineers across three sprints. She asked each engineer to reconstruct their actual time use from calendar, pull request history, Slack activity, and memory. The reconstructed time distribution for a senior engineer in a typical two-week sprint: stand-up (5 days × 15 min = 1.25 hours), sprint planning (3 hours), backlog refinement (1.5 hours), sprint retrospective (1 hour), sprint review (1 hour), 1:1 with manager (1 hour), cross-team sync (recurring, 1 hour per sprint), code review for other engineers' PRs (estimated 7.5 hours based on 15 PRs at 30 minutes each), customer support question routing from the customer success team (estimated 3 hours across the sprint), and ad hoc "quick question" requests from the PM and from other engineers (estimated 4 hours). Total non-story-point work: approximately 24 hours per sprint. The engineer worked approximately 70 coding hours per sprint (7 hours × 10 days). Non-story-point work consumed 34% of available time. The planning model allocated 100% of estimated coding hours to story points. The planning model was wrong by a third before a single story was pulled.

The over-commitment was not visible in velocity because velocity measured delivered points, not committed points. The 58% completion rate was visible, but because it was uniform across engineers and sprints, it had been attributed — incorrectly — to estimation inaccuracy: the engineers were estimating stories too small, a common failure mode in story point estimation. The correction applied in sprint 12 was a velocity inflation factor of 1.5×: estimates were multiplied by 1.5 before the sprint total was compared to the velocity target, on the theory that if the team consistently delivered 58% of committed points, the estimates must be 42% too small. This correction made the numbers balance but did not fix the planning model — it just added a correction factor on top of a broken model. Connect this to the sprint retrospective format decision record: the sprint retrospective is the calibration mechanism for the sprint planning model; a retrospective that asks "why did we miss the sprint goal?" and answers "we over-estimated our capacity" without specifying which category of non-coding work consumed the unaccounted-for time produces no actionable insight; the retrospective format that surfaces the capacity accounting gap must go one level deeper — not "we over-committed" but "we committed 42 story points and 34% of our coding time was consumed by code review and support work that was predictable but not modeled; the fix is to deduct those hours from available capacity before story allocation, not to apply an inflation factor to estimates after the fact"; the retrospective is where the planning model is questioned, not just where the sprint outcome is acknowledged.

A 37-person developer tools company built a static analysis and code quality platform — a tool that ran linting, complexity analysis, and dependency security scanning on pull requests and posted inline code review suggestions. The product had two distinct teams: a six-engineer platform team responsible for the analysis engine, the data pipeline, and the API; and a five-engineer product team responsible for the UI dashboard, the integrations with GitHub and GitLab, and the customer-facing configuration experience. The VP Engineering had come from a consultancy that used no-estimation Kanban. She introduced the model to both teams: no story points, no time estimates, no planning poker. Instead, the teams would track throughput — stories completed per sprint — and use the trailing four-sprint average throughput as the planning target for the next sprint. She had used this model successfully at the consultancy and had read the research on cycle time as a more reliable forecast input than story points.

The adoption went smoothly for the first three sprints. The platform team had a naturally disciplined backlog: their work units tended to be small and well-defined — "add support for Python 3.12 type annotations in the complexity analyzer," "fix false positive for chained method calls in the linting engine," "add Redis TTL parameter to the cache invalidation API." Stories were consistently one to three days of work. Throughput was stable: the platform team completed 7, 9, and 8 stories in the first three sprints. Sprint four was planned at 8 stories. They delivered 9. The throughput model worked.

The product team had a different backlog. Their work ranged across a wide spectrum of size: "update the dashboard loading spinner to match the new brand guidelines" (two hours), "build the new team permissions model for the GitHub org-level integration" (twelve days for two engineers), "add a webhook for PR analysis completion events" (three days), "redesign the onboarding flow for the self-serve tier" (eighteen days across three engineers). Their first three sprints under the no-estimation model pulled 6, 5, and 7 stories per sprint based on a backlog sorted by product manager priority order — whatever was highest in the backlog went into the sprint next. Sprint one delivered 11 stories: the top 5 were small UI fixes and integration tweaks, each taking two to four hours. Sprint two delivered 3 stories: the top 2 were the GitHub org-level permissions model and a redesign of the dashboard's data export flow, each taking the full sprint for the engineers involved. Sprint three delivered 6 stories. The trailing average throughput across three sprints was (11 + 3 + 6) / 3 = 6.7, which they rounded to 7 for sprint four planning. Sprint four pulled 7 stories. Three were two-to-four-hour items from the UI backlog. Four were multi-day architectural items from the integration backlog. Sprint four delivered 4 stories — the three small items and one of the four architectural items. The other three architectural items were 40–60% complete at sprint end but not shippable.

The throughput variance across four sprints was 11, 3, 6, 4 — a range from 3 to 11 on a target of 7. The planning model was producing forecasts that were accurate only in the sense that 7 was somewhere between 3 and 11. The VP Engineering recognized the problem in the sprint four retrospective: throughput-based planning requires that the unit of work — the story — have a consistent size distribution across sprints. The platform team's backlog had that consistency naturally. The product team's backlog did not. The no-estimation model had a prerequisite that had never been specified: a maximum story size standard that prevented stories larger than a threshold from entering a sprint until they had been decomposed into smaller units. Without that standard, the throughput metric measured the count of heterogeneous work units, not the count of consistent-sized work units, and a count of heterogeneous items is not a useful forecast input. Connect this to the engineering planning horizon decision record: the planning horizon decision determines the confidence window over which the engineering team can make reliable forecasts — quarterly, monthly, or sprint-level; the sprint planning model is the granular expression of that confidence window at the two-week scale; a planning horizon decision that promises quarterly delivery accuracy requires a sprint planning model that produces reliable sprint forecasts, because quarterly forecasts are aggregates of sprint forecasts; when the sprint planning model has no story size discipline and produces throughput variance of 11 to 3 on a target of 7, the quarterly forecast built on top of it is not a credible commitment but an average of unreliable averages; the planning horizon decision and the sprint planning format decision must be designed together, with the sprint-level reliability requirement specified first and the sprint planning model designed to meet that requirement, rather than adopting a planning ceremony and discovering retrospectively that it cannot support the delivery confidence the planning horizon decision assumed.

A 44-person B2B SaaS company built an enterprise contract lifecycle management platform — a tool that managed contract drafting, review, approval workflows, and renewal tracking for mid-market legal and procurement teams. The engineering team was eleven engineers organized into two product squads and a platform squad. The VP Engineering was a former engineering manager who had read widely about capacity planning, had implemented a capacity model at her previous company, and had built a careful planning system at the new company. Before each sprint, she or the squad leads ran the capacity calculation: available days per engineer minus planned time off, minus a fixed 6.5-hour deduction per engineer for sprint ceremonies, minus a 2-hour per engineer per sprint deduction for 1:1s and cross-team syncs, minus a 4-hour per engineer per sprint deduction for code review overhead. The resulting per-engineer available hours were summed, converted to story points using the team's historical velocity ratio (3.2 story points per available coding hour, derived from twelve months of data), and that capacity became the sprint commitment ceiling. The model was carefully built and consistently applied. It was correct in all the ways it accounted for.

What it did not account for was unplanned work. The company had an enterprise customer base of sixty-four accounts. Enterprise customers had contract SLAs with support response time requirements. A P1 issue — a contract workflow blocking a contract from moving to the approval stage during an active negotiation — required a response within four hours. In the twelve months the VP Engineering had data for, the engineering team had handled one to three P1/P2 incidents per sprint involving code changes (not configuration or customer education, but actual engineering work). Each incident consumed between two and twenty hours of engineering time, with a median of seven hours. The total unplanned engineering work across twelve months was approximately 380 hours, or an average of 15 hours per sprint across the team — roughly 7% of the team's sprint capacity. The variance was the problem: in some sprints, there was no unplanned work. In other sprints, a P1 incident consumed 40 hours (a contract data migration bug that required three engineers over two days to diagnose and fix without breaking customer contracts mid-negotiation). The 7% average masked a 0% to 25% range.

When a sprint had no unplanned work, the team hit 94–98% of sprint goal. When a sprint had a medium P1/P2 incident (10–15 hours), the team hit 75–85% of sprint goal and the product manager started getting risk notifications by day 8. When a sprint had a major incident (30+ hours), the sprint goal collapsed: the team delivered the hotfix, customers were satisfied, but the committed sprint stories were 30–40% complete at sprint end. The product manager had no way to predict which sprint would be disrupted. She had started building commitments to two enterprise customers for Q3 delivery of specific features, based on the VP Engineering's sprint completion data showing 92% completion rate in undisturbed sprints. In Q3, the team had two major incidents. The features were not delivered in Q3. One of the two enterprise customers sent a formal notice citing the missed delivery commitment. Connect this to the product roadmap communication decision record: the roadmap communication decision determines what delivery commitments are made to customers and with what precision; the sprint planning model is the upstream input to those commitments — a sprint planning model with no buffer policy produces delivery commitments that are reliable only under ideal conditions; the product manager and the VP Engineering were both operating correctly within their respective models: the product manager made commitments based on historical completion rate, which was accurate for undisturbed sprints; the VP Engineering planned carefully but had no buffer for incidents; the gap was at the interface between the two models — the sprint planning model was not producing a number that accounted for the actual variance of engineering work, and the roadmap communication model was not accounting for the probability of sprint disruption; the fix was a buffer policy in the sprint planning model that reserved 15% of capacity for unplanned work, which reduced average theoretical throughput by 15% but increased sprint completion rate consistency from a range of 40–98% to a range of 78–97%, giving the product manager a planning number she could build external commitments against.

Structural properties set by the sprint planning format decision

Two structural properties are determined by the founding decisions about capacity accounting, story sizing, buffer policy, and sprint goal structure. Neither is visible in sprint velocity charts or average sprint completion percentage. Both become visible when sprint commitment accuracy is measured separately from velocity, when sprint completion rate is segmented by whether the sprint contained unplanned work, and when the product manager's delivery commitment accuracy to external stakeholders is traced back to the sprint planning model that generated the forecasts those commitments were based on.

Property 1: Sprint commitment accuracy and the capacity accounting gap. Sprint commitment accuracy is the ratio of sprint goals actually met to sprint goals committed to at sprint planning. It is not the same as velocity: a team can have a stable velocity of 40 story points per sprint while committing to 65 story points and delivering 40 — the velocity is 40, the commitment accuracy is 62%, and the planning model is systematically telling the product manager, the engineering manager, and the external stakeholders that the team can deliver 65 story points of value per sprint when it can actually deliver 40. The gap is produced by the capacity accounting model: specifically, by the gap between the categories of non-coding work that the model accounts for (typically: planned time off) and the categories that it does not account for (code review, recurring ceremonies, cross-team syncs, support question routing, production context switching, and onboarding overhead for newer engineers). Each unaccounted category is individually small — code review looks like a few hours, ceremonies look like a morning — but the aggregate of all unaccounted categories is typically 30–50% of theoretical coding capacity. The commitment accuracy metric is invisible in a velocity chart because velocity measures delivered throughput, not committed versus delivered ratio. It is only visible if the planning model records what was committed at the beginning of the sprint, separately from what was delivered, and produces a commitment accuracy trend as an explicit planning health metric. The practical importance of commitment accuracy is not that missing the sprint goal is bad per se — sprint goals are intra-team planning tools and not contractual obligations — but that the product manager uses sprint completion history to set customer expectations, and a product manager who believes the team has 92% completion accuracy because velocity has been stable for twelve months is building customer commitments against a planning model that is 92% accurate only when nothing unexpected happens, which is not 92% of the time. Connect this to the sprint retrospective format decision record: the sprint retrospective is where commitment accuracy is analyzed, not just where sprint outcome is acknowledged; a retrospective format that records only "we delivered X of Y committed points" without breaking down the delivery gap by category (which categories of unplanned work consumed capacity, which story estimates were wrong and in which direction, what the capacity model predicted versus what actually happened) does not produce the signal required to improve the planning model; commitment accuracy improves only when the retrospective produces a specific diagnosis — "the code review overhead for the three large PRs from the integration refactor consumed 14 hours that the capacity model did not account for" — and a specific planning model change — "add a review overhead estimate for sprints containing large PRs to the capacity deduction calculation"; teams whose retrospectives terminate at outcome acknowledgment rather than model diagnosis will correct individual sprint misses without ever correcting the planning model that produces systematic over-commitment.

Property 2: The mid-sprint scope disruption rate and the buffer policy gap. The mid-sprint scope disruption rate is the rate at which committed sprint work is displaced by unplanned work arriving after sprint planning closes. It is set by whether the capacity model reserves explicit buffer for the demand categories that arrive outside the backlog process: production incidents requiring engineering investigation or hotfix deployment, urgent customer escalations requiring root cause analysis and bug fixes, cross-team emergencies where a dependency breaks a downstream team's critical path, and leadership-originated priority changes that arrive without the planning cycle that would have incorporated them through the backlog. Teams that plan to 100% of available capacity — even carefully modeled available capacity — experience every unplanned event as a zero-sum trade-off against committed sprint goals. A production incident consuming eight engineering hours forces one of three outcomes: the sprint goal is at risk (the committed story for those hours does not get done), the engineer works overtime (which compounds into burnout and quality problems over time), or the sprint goal is retroactively re-scoped (which degrades trust in the commitment model over time). None of these outcomes is acceptable as the default response to an event type that occurs in virtually every sprint. The buffer policy is the mechanism that converts unplanned work from a sprint goal threat into a planned contingency: 15–20% of available capacity after deductions is reserved, not allocated to sprint stories, and owned by a named decision authority (typically the product manager with engineering manager consultation for cross-function work) who determines whether a given unplanned request draws from buffer or enters the backlog for the next sprint. The effect of the buffer policy on sprint completion variance is significant: across the teams in the third case study, the pre-buffer sprint completion range was 40–98%; post-buffer, the range was 78–97%. The buffer reduced the floor from 40% to 78% without reducing the ceiling, because the buffer is sized to absorb the incidents that were previously destroying sprint goals and is not drawn in sprints where nothing unexpected happens. The apparent cost — 15–20% of theoretical throughput withheld from sprint stories — is real but smaller than it appears, because the committed throughput is the amount the team actually delivers reliably, and that sustainable committed throughput is higher than the 40–98% range average that the no-buffer model produced. Connect this to the engineering metrics decision record: the engineering metrics decision determines how sprint velocity and completion rate are used — as team performance signals, as planning inputs, or as both; teams that use sprint velocity as a performance metric create incentives for engineers to maximize delivered story points rather than reliable sprint completion, which drives story point inflation (engineers learn to estimate stories higher so the velocity number looks good) and sprint scope gaming (engineers pull small stories from the backlog when a large story stalls, maintaining the point count while not advancing the sprint goal); the buffer policy only produces reliable sprint completion signals if the metrics model uses sprint goal completion rate — did the specific sprint goal ship or not? — rather than velocity as the primary planning health metric, because velocity will not detect buffer misuse or sprint scope gaming while sprint goal completion rate will.

The sprint planning format ADR: five sections

Section 1: The capacity accounting model. The capacity accounting model section specifies the formula used to calculate available sprint capacity per engineer and per team. The formula must account for at minimum five deduction categories. First, planned time off: full days absent are deducted using the engineer's daily coding hour rate; partial-day appointments (dentist, school event, conference attendance) should be estimated to the nearest half-day. Second, recurring ceremony overhead: the total calendar time for sprint planning, backlog refinement, sprint review, retrospective, and daily stand-up must be summed and deducted; in a two-week sprint with a three-hour planning ceremony, a one-hour refinement session, a one-hour review, a one-hour retrospective, and five-minute stand-ups, the total ceremony overhead is approximately 5.8 hours per engineer; teams that run longer ceremonies or more refinement sessions must use their actual numbers, not industry defaults. Third, code review tax: the team's historical average hours per sprint spent reviewing others' code, not included in any story estimate; this requires a one-time measurement exercise (calendar analysis or time tracking over two to three sprints) to establish the baseline, after which the baseline is updated quarterly; in a five-engineer team with active code review culture, this is typically 4–7 hours per engineer per sprint. Fourth, on-call rotation impact: engineers carrying the production pager should be planned at 70–80% of their nominal post-deduction capacity, with the specific percentage derived from the team's historical incident rate and average incident duration; the calculation is (probability of at least one incident per sprint) × (average incident duration) × (proportion attributable to the on-call engineer's investigation time) — teams with clean production systems and good runbook coverage will have lower percentages than teams in active scaling phases. Fifth, explicit unplanned work buffer: 15–20% of total post-deduction capacity is withheld from story allocation; this is the buffer percentage, not an estimate of expected unplanned work — it is a structural reserve that is not allocated regardless of how calm recent sprints have been. The buffer percentage is revisited quarterly based on trailing unplanned work volume: if average unplanned work consumption has been consistently below 10% for two quarters, the buffer may be reduced to 12–15%; if it has been consistently above 20%, the buffer should be raised to 25%. The capacity model is documented as a named formula in the team's planning wiki, not as implicit knowledge in the engineering manager's spreadsheet — the formula must be auditable by anyone joining the team, and the input values (hours per ceremony, code review baseline, on-call percentage) must be versioned so the team can see how the model has changed over time. Connect this to the sprint retrospective format decision record: each sprint retrospective should include a one-line capacity model audit — comparing the planned capacity per engineer against the reconstructed actual capacity for two or three engineers — to detect model drift; if the audit consistently shows a specific deduction category growing larger than the model estimates (code review hours increasing as the codebase grows, ceremony time creeping as the team adds meetings), that is a model update signal; teams that treat the capacity model as a one-time setup exercise rather than a living formula will find it drifting away from reality within three to six months of the initial calibration.

Section 2: Story sizing and commitment standard. The sizing and commitment section specifies three decisions: the story sizing model (story points, t-shirt sizes, cycle time, or count-based throughput), the maximum story size standard, and the sprint commitment standard. The story sizing model choice has one prerequisite that applies to all models: a maximum story size standard that must be met before any story enters sprint planning. The standard is expressed as a duration — the maximum amount of time a single story should require for one engineer working on it without interruption — and the standard is typically set at half the sprint duration: in a two-week sprint, no story committed to the sprint should require more than five working days for one engineer; stories estimated above that threshold must be split into two or more stories, each meeting the standard, before sprint planning. The maximum size standard serves both the story points model (stories above the threshold are typically estimated at 8 or 13 points, which are the size ranges where estimation error is highest and where the story is a sprint goal risk) and the throughput model (stories above the threshold break the size consistency assumption that throughput-based planning requires). The split discipline is the practical bottleneck: most backlogs contain stories that are sized above the standard because decomposition is harder than writing the original story, and product managers resist splitting because it fragments the feature narrative into implementation details that are harder to communicate to stakeholders; the planning format must specify who has the authority to require a split (typically the engineering manager, in consultation with the product manager), what the process is for splitting (a brief decomposition exercise at refinement, not mid-sprint), and what happens when a story cannot be split to meet the standard (it enters the sprint as a research spike with a specific deliverable — a written recommendation, a prototype, a proof-of-concept — not an open-ended investigation). The sprint commitment standard specifies what "committed to the sprint" means: the sprint goal, which is the deliverable that the team commits to producing; supporting stories, which are work the team plans to complete and which contribute to sprint goal delivery but which are not individually committed; and pulled-for-capacity-fill stories, which are backlog items pulled to use buffer capacity that is not consumed by unplanned work. These three categories must be explicitly labeled in the sprint backlog so that sprint goal evaluation is unambiguous — did the sprint goal ship, regardless of the supporting story completion percentage? — and so that mid-sprint scope changes have a clear impact assessment: replacing a supporting story mid-sprint is a planning adjustment; replacing the sprint goal mid-sprint is a commitment change that requires explicit acknowledgment from both the product manager and the engineering manager. Connect this to the engineering planning horizon decision record: the planning horizon decision specifies the delivery confidence windows over which the engineering team can make reliable forecasts; the sprint commitment standard is the micro-instance of that confidence model at the two-week scale; a sprint commitment standard that treats all stories as equal commitments produces sprint goal ambiguity — if 8 of 9 stories are done, is the sprint a success? — and that ambiguity propagates upward into quarterly planning where the answer to "will we hit the Q3 milestone?" is "we delivered 89% of our story points" instead of "we delivered 100% of our sprint goals"; quarterly planning accuracy requires sprint goal accuracy, which requires a sprint commitment standard that identifies the sprint goal separately from the supporting work.

Section 3: The buffer policy. The buffer policy section specifies the buffer amount, the ownership model, and the draw process. The buffer amount is specified as a percentage of post-deduction available capacity — standard range 15–20% — and is physically reserved in the sprint backlog as unallocated capacity rather than allocated to a named story. The physical reservation is important: a buffer that exists only as a mental model or as a verbal agreement will be absorbed by the first strong request, because the person making the request can see empty capacity in the sprint backlog and does not know that the capacity has been reserved. The ownership model specifies who has authority to allocate buffer and what each decision authority's scope is. Three standard ownership assignments: the engineering manager has authority to allocate buffer for production incidents of P1/P2 severity without requiring product manager approval, because production incidents have customer impact and cannot wait for a planning discussion; the product manager has authority to allocate buffer for urgent customer escalations that require engineering investigation or hotfix, in consultation with the engineering manager on scope; the engineering manager and product manager jointly have authority to allocate buffer for cross-team dependency emergencies or leadership-originated priority changes. Buffer draws must be recorded in the sprint backlog with the date, the work type, the hours consumed, and the approving authority — this record is the input to the quarterly buffer sizing review. The draw process for non-incident work must include a scope specification: before any non-incident work draws from buffer, the requester must specify the deliverable (not "look into the customer's data problem" but "determine whether the customer's data problem is a bug in the pipeline or a configuration issue, and produce a written finding within four hours"), the estimated hours, and the engineer assigned; open-ended buffer draws are not permitted because they are indistinguishable from scope creep. When buffer is exhausted before the sprint ends, the escalation path is: engineering manager calls a scope discussion with the product manager; the team identifies which supporting stories from the sprint can be moved to the next sprint's backlog without affecting the sprint goal; the sprint goal is protected unless the disruption was so large that the sprint goal is materially affected, in which case the product manager must explicitly acknowledge the sprint goal miss and its cause rather than retroactively re-scoping the goal to match what was delivered. Connect this to the product roadmap communication decision record: the buffer policy is the mechanism that determines how reliably sprint forecasts can serve as inputs to roadmap commitments; a sprint with no buffer policy produces sprint completion variance so high that the product manager cannot distinguish "this sprint was disrupted by an incident" from "this sprint was normally planned but delivered less than usual"; when the variance is attributable, the product manager can account for it in roadmap communication ("we had a major incident in sprint 7 that consumed 35 hours of engineering capacity; the feature is delayed by one sprint, not by a planning failure"); when the variance is unattributed, it looks like unreliable engineering rather than like the consequence of a correctly-applied triage decision, and it degrades the product manager's confidence in engineering forecasts in exactly the quarters when accurate forecasting is most important for customer relationship management.

Section 4: Sprint goal structure and evaluation. The sprint goal section specifies the form of the sprint goal statement, the evaluation standard at sprint retrospective, and the labeling convention for work that is in the sprint but is not the sprint goal. The form standard for sprint goal statements is a deliverable form, not a story-list form and not a theme form. A deliverable form sprint goal names a specific, observable outcome that either exists or does not exist at sprint end: "contract renewal workflow is deployed to production and passes QA sign-off on the three critical path scenarios identified in the design review" is a deliverable form; "improve the contract renewal experience" is a theme form; "complete stories CL-412, CL-413, CL-415, and CL-421" is a story-list form. Only the deliverable form is evaluable: the theme form can always be claimed as met (something was improved), and the story-list form requires negotiating whether 3 of 4 stories constitutes goal completion. The evaluation standard at sprint retrospective is binary: the sprint goal either shipped or did not ship, and the evaluation is made against the deliverable specification in the sprint goal statement, not against a revised version of the goal that was narrowed mid-sprint. If the sprint goal did not ship, the retrospective must record why — which of the four categories produced the miss (capacity accounting gap, story size violation, buffer exhaustion, estimation error) — and produce a planning model change for the next sprint. The labeling convention distinguishes three categories in the sprint backlog: sprint goal stories (the work required to meet the deliverable specification), supporting stories (work that is planned and expected to complete but which is not on the critical path to the sprint goal deliverable), and capacity-fill stories (backlog items pulled to use buffer capacity; these are the first to be de-committed if buffer is consumed by unplanned work). The labeling convention serves the scope change authority model: a request to change a capacity-fill story mid-sprint requires no authority discussion because the story was never committed; a request to change a supporting story requires product manager acknowledgment; a request to change the sprint goal requires both product manager and engineering manager acknowledgment and a written record of the cause. Connect this to the sprint retrospective format decision record: the sprint retrospective format must have a dedicated sprint goal evaluation section that applies the binary evaluation standard and produces a written record of the cause when the goal was not met; retrospective formats that conflate sprint goal evaluation with sprint health discussion ("how did the sprint go overall?") lose the signal that sprint goal evaluation provides — a team can have a healthy sprint (good collaboration, no conflicts, engineers felt productive) that missed the sprint goal, and a sprint that felt difficult (two production incidents, late nights) that met the sprint goal; the sprint health and the sprint goal outcome are separate signals that require separate evaluation questions.

Section 5: Planning ceremony format and mid-sprint authority. The ceremony format section specifies the attendee list, each attendee's decision authority, the ceremony time box, and the authority model for mid-sprint scope changes. Sprint planning attendees have distinct roles: the product manager owns the backlog priority ordering and the sprint goal definition; the engineering manager owns the capacity model and the commitment standard; the engineers own the story estimates and the technical feasibility assessment; the QA engineer (if present) owns the QA effort estimate for stories requiring testing before the sprint goal deliverable is complete. The decision authority matrix must specify: who can override the capacity calculation (no one — the capacity model is applied mechanically; if the product manager believes more work should fit in the sprint, the discussion is about whether the capacity model inputs are correct, not about whether to exceed the capacity model output); who can change the sprint goal after planning closes (product manager and engineering manager jointly, with written record and cause statement); who can introduce new work mid-sprint (engineering manager for incidents and operational emergencies, drawing from buffer per the buffer policy; product manager for urgent customer escalations, drawing from buffer per the buffer policy; neither authority introduces work mid-sprint that exceeds buffer capacity without a formal re-planning conversation). The ceremony time box must be set against the sprint duration: for a two-week sprint, three hours for sprint planning is the standard upper bound; for a one-week sprint, ninety minutes; for teams running consistently over the time box, the over-run is a diagnostic signal (backlog refinement is not happening, stories are entering planning unsized or unscoped, the product manager and engineering manager are using planning to negotiate scope rather than to convert an already-prioritized and sized backlog into a sprint commitment). The mid-sprint risk trigger must be explicit: the engineering manager calls a scope discussion with the product manager when the sprint goal is at risk with more than three working days remaining — not on the last day, when the scope discussion produces either a retroactive re-scope or a miss acknowledgment, but with enough time to either re-plan supporting stories (protecting the sprint goal by de-committing lower-priority work) or to communicate the risk to stakeholders before the sprint ends. Connect this to the open-source extractor: the sprint planning format decisions — why the capacity buffer is 18% rather than 10%, why story points were abandoned in favor of cycle time after the product team's throughput variance became unmanageable, why the sprint goal standard was changed from "any committed stories" to a specific deliverable form after the engineering manager noticed that sprint goal evaluations were being gamed by retroactively narrowing the goal definition to match what was delivered, what the authority matrix is for mid-sprint scope changes and why it was designed to require both product manager and engineering manager acknowledgment rather than either authority acting unilaterally — these are decisions made in conversations: a VP Engineering and an engineering manager debating whether the 20% buffer is too conservative and is reducing perceived throughput without delivering proportional reliability improvements; a sprint retrospective where the product manager and engineering manager agree that the sprint goal form standard needs to change because the last three goals were evaluated ambiguously; a post-incident review where the question "why did the sprint goal miss?" produces a planning model change rather than a one-time exception acknowledgment; the written output is the sprint planning ADR update and the planning wiki change; the reasoning behind those choices — why those specific buffer percentages, why those specific authority boundaries, what tradeoffs were made between theoretical throughput and reliable commitment — lives in the conversation history that preceded the documented decisions, and it is exactly the kind of operational reasoning that WhyChose's extractor recovers from AI chat export history and makes searchable when the question is why the sprint planning model was designed the way it was and whether the original tradeoffs still hold after the team has grown, the product has matured, and the customer base has developed roadmap commitment expectations that the original planning model was not designed to support.

FAQ

Further reading

• Sprint retrospective format decision record — the retrospective is the calibration mechanism for the sprint planning model; the retrospective format that improves planning accuracy must go beyond outcome acknowledgment ("we delivered 60% of committed points") to model diagnosis ("the capacity model under-estimated code review overhead by 12 hours because three large PRs were in flight simultaneously, and the fix is to add a large-PR review overhead deduction for sprints where any story is estimated above 5 points"); teams whose retrospectives terminate at outcome acknowledgment will correct individual sprint misses but never correct the planning model that produces systematic over-commitment, and the capacity accounting gap will compound sprint over sprint until the product manager stops trusting sprint forecasts as planning inputs.
• Engineering planning horizon decision record — the planning horizon decision specifies the confidence windows over which the engineering team can make reliable delivery forecasts — quarterly, monthly, sprint-level; the sprint planning model is the granular input to those forecasts, and a sprint commitment standard that produces 40–98% completion variance does not support a planning horizon decision that promises quarterly delivery reliability; the planning horizon and the sprint planning format must be designed together, with the sprint-level reliability requirement specified first and the sprint planning model designed to meet that requirement, because quarterly forecasts that are aggregates of unreliable sprint forecasts are not quarterly forecasts but quarterly hopes.
• Product roadmap communication decision record — roadmap communication decisions about what to commit to customers and with what precision are downstream of the sprint planning model's reliability; a product manager who believes the team has 92% sprint completion accuracy because the last twelve months showed stable velocity is building customer commitments against a planning number that is only accurate when nothing goes wrong; the roadmap communication decision must be calibrated against the actual sprint completion variance — not the average — and the sprint planning format decision, specifically the buffer policy, is the lever that reduces that variance from a 40–98% range to a 78–97% range without reducing sustainable throughput, giving the product manager a planning number she can build external commitments against with honesty rather than optimism.
• Engineering metrics decision record — the engineering metrics decision determines how sprint velocity and completion rate are used — as team performance signals, as planning inputs, or as both; using sprint velocity as a performance metric creates incentives for story point inflation (engineers learn to estimate stories higher to maintain the velocity number) and sprint scope gaming (pulling small stories from the backlog when a large story stalls), both of which corrupt the planning model while keeping the velocity metric healthy; the buffer policy only produces reliable sprint commitment signals if the primary planning health metric is sprint goal completion rate — binary, evaluable — rather than velocity, which cannot detect buffer misuse or scope gaming and which will show a healthy trend even while sprint goals are being systematically missed by 40%.
• Open-source extractor — the sprint planning format decisions — why the unplanned work buffer is 18% rather than 10%, why the team switched from story points to cycle time after the no-estimation experiment revealed that story size consistency was not being maintained, why the sprint goal form standard changed from story lists to deliverable statements after three consecutive sprints of ambiguous goal evaluation, what authority boundaries govern mid-sprint scope changes and why the product manager and engineering manager must jointly acknowledge sprint goal changes rather than either acting unilaterally — are made in conversations: a VP Engineering and an engineering manager retrospecting on a year of 58% sprint completion and working backward to the planning model as the root cause; a sprint planning ceremony where the product manager argues for committing to more stories than the capacity model allows and the engineering manager explains the buffer policy and the variance data that justify it; the written output is the sprint planning ADR and the planning wiki update; the reasoning behind those decisions — the empirical data that calibrated the buffer percentage, the specific incidents that made the 100% allocation model's failure mode visible, the team dynamics that made the sprint goal form standard change necessary — lives in the conversation history that preceded the documented decisions, and that is exactly what WhyChose's extractor recovers from AI chat export history and makes searchable when the next engineering manager inherits the planning system and needs to understand not just what the decisions were but why they were made and whether the original conditions that justified them still apply.