The sprint velocity forecasting decision record: why the forecasting model you chose determines your delivery predictability ceiling and your stakeholder expectation alignment surface

An 18-person B2B developer tools company had been running two-week sprints for fourteen months. The engineering team tracked velocity using an 8-sprint rolling average, updated at the end of each sprint and visible in the planning board. The rolling average for the three months leading into Q3 annual planning was 47 story points per sprint. The CTO committed to a board partner during the Q2 quarterly business review that a new enterprise compliance reporting module — estimated by the engineering team at 188 story points — would ship before the end of Q3. The 8-sprint rolling average said four sprints at the historical rate, which fit comfortably inside Q3's five available sprints with a one-sprint buffer. The commitment was verbal, made during a slide presentation, and recorded in the board partner's notes as "compliance module in Q3."

The commitment was made without surfacing the variance underlying the average. The same 8 sprints that produced a 47-point average had individual velocities of 31, 52, 44, 67, 38, 51, 42, and 57 story points. The standard deviation was 10.4 story points — a coefficient of variation of 22%, meaning any given sprint was as likely to deliver 37 points as it was to deliver 57. A simple Monte Carlo simulation using the actual velocity distribution would have shown a P50 completion of 4.1 sprints, a P70 completion of 5.3 sprints, and a P90 completion of 6.7 sprints — the compliance module had approximately a 30% chance of missing Q3 even with no unusual events. No probabilistic framing was applied. The board partner received a binary statement that the module would be in production before Q3 ended.

The module shipped in week three of Q4 — five weeks after the committed deadline. Two sprints ran significantly below the historical average: one sprint delivered 28 story points because a production security vulnerability was discovered in the OAuth implementation and two engineers spent six days on a partial-credential rotation, incident documentation, and customer disclosure rather than on compliance module work; one sprint delivered 33 story points because the three most technically complex stories in the module required architectural decisions about the audit event schema that surfaced incompatibilities with the existing event pipeline, adding two weeks of design work that appeared as velocity suppression rather than as scope expansion. Neither event was unusual or statistically improbable — security incidents and architectural surprises had both appeared in the team's prior sprint history. The rolling average model had data about these events in its 8-sprint window; it had averaged them away rather than modeling their probability and incorporating that probability into the confidence interval on the delivery estimate. The board partner raised the missed commitment as an execution credibility concern in the Series A due diligence process. The CTO's explanation — that the engineering team had worked effectively, that the module was technically sound, and that the delay reflected normal variance in software delivery — was accurate. It did not address the partner's underlying concern, which was not about whether this specific module was delivered late but about whether the CTO's future commitments could be trusted to carry the same epistemic weight as a vendor contract or an accountant's cash flow projection.

A 45-person B2B SaaS had four engineering teams. Over a six-month period beginning in February, the organization hired five engineers distributed across three of the four teams: one senior engineer joining the platform team, two mid-level engineers joining the product team, and two junior engineers joining the growth team. Before the hiring wave began, the combined four-team velocity across the prior three quarters was 198, 211, and 204 story points per two-week sprint cycle. The H2 annual roadmap was planned in January using the Q1-through-Q3 historical average: 204 points per sprint, 12 sprints across H2, yielding 2,448 story points of roadmap work distributed across the four teams and committed to product leadership and to two enterprise customers whose annual contract renewals included feature delivery annexes.

The forecasting model had no adjustment mechanism for the learning curve effect of new team members. Each engineer joining an established team suppresses that team's velocity for three to five sprints: the new engineer works through a ramp period of increasingly autonomous contributions, the engineers who onboard and pair with the new hire have a portion of their own sprint capacity absorbed into mentoring and code review rather than net-new feature delivery, and the team as a whole works through the social and technical adjustment of redistributing ownership and review responsibility across a changed composition. The five new hires joining across three teams in a compressed six-month window produced overlapping learning curve suppressions in Q2 and Q3. The two junior engineers joining the growth team in April each required the longest ramp period — approximately five sprints before reaching full autonomous contribution — and their ramp periods ran concurrently rather than sequentially, multiplying the suppression effect on the growth team. The combined four-team velocity across the first four sprints of H2 was 147, 162, 158, and 171 points per sprint — averaging 160 points per sprint against a forecasted baseline of 204, a 22% shortfall during the suppression window.

Actual H2 delivery was 1,641 story points against a forecasted commitment of 2,448 — 67% completion. Three features included in the enterprise customer delivery annexes were among the shortfall. The engineering director's explanation to the CEO was that velocity would normalize after the new hires completed their ramp period, which was accurate — Q1 of the following year showed a combined velocity of 227 story points per sprint, 11% above the pre-growth baseline, demonstrating that the hiring decision had been correct. The point that the explanation did not address was that the forecasting model had no mechanism for modeling the transition period between the pre-growth team and the post-growth team. The roadmap had been planned as if the five new hires would contribute at full velocity on their first sprint and would impose no capacity cost on the engineers around them. The organization had correctly anticipated that growth would accelerate delivery in the medium term; the forecasting model had treated the acceleration as beginning immediately rather than after a ramp period whose length was predictable from the seniority and number of new hires. Connect this to the capacity planning decision record: the learning curve suppression that the forecasting model failed to account for was not an unexpected event — it was a predictable consequence of the hiring plan that the capacity model should have incorporated as a forecasting parameter, not discovered as a delivery shortfall three quarters later.

A 65-person enterprise SaaS building a workforce management platform had invested in a technically mature velocity forecasting model. The head of engineering had built the model over three quarters with input from a data analyst: it used a rolling 6-sprint average for each of the organization's six engineering teams, applied a PTO and company-holiday capacity correction factor to the projected sprint denominator, incorporated a team-composition correction factor for the first four sprints following any team membership change (calibrated from the team's own historical post-hire velocity data), and ran a 10,000-iteration Monte Carlo simulation using the team's historical velocity distribution to generate P50, P70, and P90 delivery dates for each roadmap item. The model correctly captured the asymmetric nature of software delivery variance — slippage was more probable than early delivery in the historical data, and the P50 and P70 estimates reflected that asymmetry. The head of engineering presented forecasts to product leadership in quarterly planning sessions with all three confidence intervals visible: a major integration feature's forecast read "P50: Q2 week 4, P70: Q3 week 1, P90: Q3 week 8." Everyone in the planning session understood that P50 meant a 50% probability of delivering by that date, not a commitment to deliver by that date.

The problem was downstream of the forecasting model and invisible to the engineering organization until it produced an invoice. The sales team, working from a roadmap document that the head of engineering had shared with the VP of Sales as context for the H1 renewal pipeline, had extracted the P50 delivery dates and used them as the basis for contractual delivery clauses in two enterprise renewal negotiations. The VP of Sales had understood the P50/P70/P90 framing in the context of a planning presentation but had not built a conversion protocol into the sales team's quoting process — when an account executive needed a delivery date to include in a contract, the account executive used the roadmap document as the authoritative source and picked the earliest date associated with the feature, which was the P50 estimate. Two enterprise customers signed annual contracts in Q1 that included the integration feature with a Q2 week-four delivery clause. The head of engineering had not been consulted before the contracts were signed.

The integration feature slipped to Q3 week 2. This was a normal-variance outcome by the forecasting model's own assessment: the P50 completion date was Q2 week 4, which meant there was a 50% probability of delivering after Q2 week 4, and Q3 week 2 was within the P70 range. The engineering teams had executed well; the delivery reflected the inherent uncertainty in software output, which the Monte Carlo model had quantified correctly. Both customers invoked contractual delivery penalty clauses worth a combined $47,000. The penalty process consumed six weeks of legal and account management time in addition to the direct cost. The head of engineering's retrospective analysis confirmed that the forecasting model's P90 estimate for the integration feature had been Q3 week 8 — a date that no customer had agreed to as a delivery commitment and that the sales team had never quoted because it was the furthest date on the forecast sheet. The organization had the technical capability to produce an accurate probability distribution over delivery outcomes. It lacked a process that linked the confidence level of a forecast to the type of organizational commitment that confidence level could support. Connect this to the product sprint review decision record: the delivery signal that would have surfaced the contract risk — the integration feature's sprint-by-sprint progress against the P50 forecast trajectory — was available in the sprint review, but the sprint review had no agenda item for comparing current sprint delivery rates against the confidence intervals that had been used to generate customer commitments; the review focused on what had shipped this sprint, not on whether the delivery rate was consistent with the P70 completion path that would have kept the feature within the contracted window.

Structural properties set by the sprint velocity forecasting decision

Two structural properties are determined by the founding decisions about how velocity is measured, how it is projected into a delivery estimate, and how the estimate is converted into an organizational commitment. Neither property is visible when the planning horizon is short and stakeholder commitments are informal. Both become visible when a board partner writes a concern into due diligence notes, when a contract penalty clause is triggered, or when a roadmap retrospective reveals that actual delivery was systematically below the plan the organization used to make customer promises.

Property 1: Delivery predictability ceiling. The delivery predictability ceiling is the maximum reliability with which the team can accurately forecast its output over a given planning horizon — the degree to which the team's delivery estimates actually contain the real delivery outcome at the stated confidence level. A team whose velocity forecasting model uses average velocity as a point estimate with no variance model has a low predictability ceiling: its forecasts will be accurate in expectation (the average will be close to the median outcome over many forecasts) but systematically overconfident at every stated interval (when the team says "we will deliver this in four sprints," they are implicitly stating 100% confidence in a model that the data does not support at 100% confidence). A team whose model computes P50/P70/P90 estimates from the historical velocity distribution has a higher predictability ceiling: the P70 estimate should contain the actual outcome 70% of the time, and the team's stakeholders have an instrument for choosing the commitment level they want based on the consequence of being wrong. The predictability ceiling is also bounded by the model's ability to capture variance sources that are not well-represented in historical velocity data: a team that has not had a major production incident in the last 8 sprints has no incident-suppression signal in its velocity history, and its 8-sprint rolling average will forecast future sprints as if incident risk does not exist. Explicit risk buffering — adding a probabilistic adjustment for incident risk, architectural surprise risk, and key-person dependency risk — extends the predictability ceiling beyond what the historical distribution alone can provide. The 18-person startup's rolling average model had a low predictability ceiling not because the underlying data was wrong but because the model made no distinction between the expected outcome and any particular confidence level, and that distinction is exactly what the board partner needed to calibrate their trust in the CTO's commitment.

Property 2: Stakeholder expectation alignment surface. The stakeholder expectation alignment surface is the gap between what the forecasting model estimates as the probable delivery range and what the stakeholders who receive the forecast — customers, board members, sales teams, product leadership — believe has been committed by the engineering organization. A forecast communicated as a single date produces the maximum misalignment surface: the recipient cannot distinguish between a P50 estimate and a P90 estimate because both are expressed as a date, and recipients will typically interpret a date stated by an engineering leader as a commitment rather than as a central estimate in a distribution. The expectation alignment surface depends on both the communication format (does the forecast include confidence levels, or is it a single date?) and the commitment conversion protocol (is there a defined rule for which confidence level can be used as the basis for each type of commitment?). The 65-person enterprise SaaS had solved the communication format problem — everyone in the planning session understood the P50/P70/P90 framing — but had not solved the conversion protocol problem: there was no rule that bound the sales team's quoting behavior to a specific confidence interval, and in the absence of such a rule the default behavior was to quote the most optimistic date that appeared in the engineering organization's official communication. Connect this to the engineering planning horizon decision record: the planning horizon model determines what time window the forecast covers, while the commitment conversion protocol determines how the forecast is used once it reaches stakeholders; a quarterly planning horizon with no commitment conversion protocol is a technical improvement over a sprint-only planning horizon, but it adds expectation alignment risk whenever the detailed forecast document is shared outside the engineering organization without the framing that makes the confidence intervals interpretable.

The sprint velocity forecasting ADR: five sections

Section 1: Velocity metric selection and variance model. The velocity metric selection specifies what the team treats as its primary output signal and how it models the uncertainty in that signal. The most common failure mode in velocity metric selection is choosing average velocity as the sole forecasting input — average velocity is a correct measure of central tendency but provides no information about the probability of outcomes that differ from the central estimate, which is precisely the information that makes a forecast useful for commitment decisions. The variance model should be built from the team's own historical velocity data and should include at minimum: the rolling average adjusted for planned capacity (PTO, holidays, expected interruptions), the standard deviation of the historical velocity distribution, and an assessment of whether the distribution is approximately symmetric or left-skewed (engineering teams typically have more low-velocity sprints from disruptions than high-velocity sprints from unusual focus). The ADR should record the team's current velocity distribution — not just the average but the full historical sprint record — so that the model's calibration basis is explicit and the model can be validated against future actuals. It should also specify the rolling window length and justify the choice: a longer window (8–12 sprints) smooths out noise but responds slowly to genuine changes in the team's output capacity; a shorter window (4–6 sprints) is more responsive but more sensitive to transient variance. Teams that have recently changed composition, tooling, or process should use a shorter window to reflect current conditions rather than historical conditions that no longer describe the team. The velocity metric should be measured consistently across sprints — if the team excludes bug fixes from velocity one quarter and includes them the next, the resulting distribution is not comparable across the window and will produce forecasts that are either systematically optimistic or systematically pessimistic depending on which convention the current sprint follows.

Section 2: Forecast horizon model and confidence interval generation. The forecast horizon model specifies how far in advance the team generates delivery estimates, at what confidence levels, and what method is used to generate those estimates. The minimum requirement for a forecast that supports commitment decisions is a P50 estimate (the expected outcome, expressly labeled as a 50% probability target rather than as a delivery commitment) and a P90 estimate (the high-confidence delivery date appropriate for external commitments with meaningful consequences). Generating these estimates from historical velocity data requires either Monte Carlo simulation or a simplified analytical method. Monte Carlo simulation is more accurate: model each future sprint as a random draw from the historical velocity distribution, simulate thousands of possible futures, and read off the percentile completion dates directly. The simplified analytical method uses the mean and standard deviation of the velocity distribution to compute confidence intervals analytically under a normal approximation — less accurate when the velocity distribution is skewed but computationally trivial and adequate for planning purposes when the forecast horizon is long enough (more than four to five sprints) that the central limit theorem brings the sprint-sum distribution close to normal. The forecast horizon model should specify the maximum useful forecast horizon — the number of sprints into the future at which the confidence interval on the delivery estimate becomes too wide to be useful for planning. For most teams this is six to ten sprints: beyond that horizon, the uncertainty range between P50 and P90 is so large that stakeholders cannot meaningfully plan around the estimate, and the forecast should be communicated as a rough directional indication rather than as a date-level projection. Connect this to the sprint planning format decision record: the sprint planning format model determines what inputs are available to the forecasting model at the start of each sprint — specifically, whether the sprint planning process produces consistent story point estimates, consistent scope definitions, and consistent treatment of unplanned work; a sprint planning format that does not reliably produce these inputs will generate velocity data with noise introduced by estimation inconsistency rather than by genuine output variation, and the forecasting model's confidence intervals will overstate the team's actual predictability ceiling because the variance in the data reflects estimation process variance as much as it reflects delivery variance.

Section 3: Team composition adjustment protocol. The team composition adjustment protocol specifies how the velocity forecast is modified when team membership changes — specifically, the correction factors applied to the forecast during the learning curve period following a new hire's start date, and the model for when the correction factor is removed as the new hire reaches full contribution. The protocol should be calibrated from the team's own historical post-hire velocity data: for each of the last three to five new hires, measure the team's velocity in the four sprints after the hire's start date relative to the team's velocity baseline in the four sprints before the hire's start date, and compute the average suppression percentage and the sprint at which velocity returned to baseline. In the absence of team-specific calibration data, reasonable starting assumptions are: a 15–20% velocity suppression for a junior engineer across sprints 1–4 post-start, tapering to zero by sprint 5; 10–15% suppression for a mid-level engineer across sprints 1–3 post-start; 5–8% suppression for a senior engineer in sprint 1–2 post-start. Two interactions that the protocol should model explicitly: when multiple engineers join the same team within the same quarter, their learning curve suppressions overlap and the aggregate suppression is larger than the sum of the individual corrections, because the senior engineers absorbing the onboarding load have their own velocity suppressed simultaneously; and when the hiring plan calls for engineers to join across multiple teams in the same quarter, the aggregate organizational velocity suppression should be tracked at the portfolio level in the roadmap forecast, not just team-by-team, because the cross-team suppression is what determines whether the quarterly roadmap commitment is achievable. The ADR should specify the escalation threshold: if the projected post-hire suppression will reduce team velocity below the level needed to meet an existing roadmap commitment, the engineering lead should surface the commitment risk to product leadership before the hire's start date, not after the suppression appears in the sprint review data.

Section 4: Commitment communication protocol. The commitment communication protocol specifies how velocity-based forecasts are translated into organizational commitments, and which confidence level is the appropriate basis for each type of commitment. The protocol has three components. The delivery estimate format defines how engineering leaders present forecasts to stakeholders outside the engineering team: every delivery estimate communicated outside an engineering planning session should include the confidence level to which the estimate applies, even if the confidence level is expressed in plain language rather than statistical notation ("we expect this to be done by Q2 week 4; our high-confidence date is Q3 week 8"). Omitting the confidence level converts a probabilistic estimate into an implied commitment, because recipients who do not know that the date is a 50% estimate will interpret it as the engineering team's stated delivery target. The commitment conversion rule defines which confidence level can be used as the basis for each category of organizational commitment: internal planning (sprint and quarterly roadmap) should use P50 or P70 estimates; external roadmap documents shared with customers should use P70 or higher; contractual delivery clauses should use P85 or P90 estimates and should be reviewed by the head of engineering before the contract is signed. The review gate specifies that any customer contract containing a delivery date for software features requires sign-off from the engineering leader who owns the relevant forecast before the contract is finalized, with the sign-off explicitly confirming that the committed date corresponds to the engineering team's P85 or P90 estimate for the feature in question. Without the review gate, the commitment communication protocol is a guideline that is followed when convenient and bypassed when a deal needs to close, and the consequence appears as a penalty clause rather than as a planning error.

Section 5: Forecast retrospective and calibration cadence. The forecast retrospective and calibration cadence specifies how the forecasting model is evaluated against actual delivery outcomes, how model parameters are updated when the model's predictions are consistently wrong, and how often calibration runs. Forecasting models degrade silently: a team whose velocity distribution has shifted due to changes in team composition, tooling, or work type will continue producing confident-looking forecasts from a distribution that no longer matches current reality, and the degradation is not visible until a sequence of missed commitments provides enough data to diagnose it. The retrospective should run quarterly and should measure three things: forecast calibration (did the P70 estimates contain the actual outcome 70% of the time? If consistently less than 70%, the variance model is underestimating uncertainty; if consistently more, it may be too conservative), systematic bias (do forecasts consistently overshoot or undershoot actual delivery? Consistent overshooting implies the capacity correction factors are too generous; consistent undershooting implies the rolling window is dominated by historical sprints that are no longer representative of current team capacity), and the learning curve correction accuracy (for hires who completed their ramp period in the previous quarter, how close was the predicted suppression to the actual suppression? Adjusting the correction factors based on actual ramp data improves model calibration over time). The ADR should specify the owner of the calibration process — typically the engineering director or the head of engineering rather than an individual team lead — because calibration requires access to historical velocity data across teams and comparison against roadmap commitments, neither of which is typically visible at the team level. Connect this to the technical roadmap prioritization decision record: the roadmap prioritization model determines what work the team commits to; the velocity forecast model determines when that work will be done; and the forecast retrospective determines whether the forecast model is accurate enough to support the commitment certainty that the prioritization model requires; a team that prioritizes roadmap work based on four-sprint delivery estimates and has a forecast model that is calibrated at P50 accuracy (actual outcome is within the P50–P90 range 50% of the time, not 70%) is making prioritization commitments based on a model that overstates delivery certainty by 20 percentage points, and the roadmap will systematically over-commit because the prioritization model assumes the forecast is more reliable than it actually is.

FAQ

Further reading

• Sprint planning format decision record — the sprint planning format model and the velocity forecasting model are directly coupled inputs and outputs: the sprint planning format determines what estimation practices the team uses (story points, days, T-shirt sizes, no estimates), whether estimates are produced by the whole team or by individuals, and how unplanned work is classified when it enters the sprint mid-cycle; each of these decisions affects the quality of the velocity signal that the forecasting model consumes, because velocity data generated by inconsistent estimation practices has noise introduced by the estimation process itself rather than solely by genuine output variation, and a forecasting model built on noisy velocity data will produce confidence intervals that overstate the team's actual predictability ceiling.
• Engineering planning horizon decision record — the planning horizon model determines how far into the future the organization commits to a roadmap, and the velocity forecasting model determines how reliable those commitments are at each horizon; a quarterly planning horizon with P50-only velocity forecasts produces quarterly commitments that are correct approximately half the time, which is often better than no quarterly planning but is systematically insufficient for organizations that translate quarterly roadmap commitments into customer delivery clauses; the combination of a longer planning horizon and a variance-aware forecasting model (P70–P90 estimates) is what makes multi-quarter roadmap commitments defensible rather than aspirational.
• Capacity planning decision record — the capacity planning model and the velocity forecasting model address adjacent but distinct questions: capacity planning determines how many engineer-sprints are available per quarter (adjusting for headcount, PTO, and planned interruptions), while velocity forecasting determines what output those engineer-sprints will produce given the team's historical conversion rate of capacity into shipped work; the two models interact most visibly during hiring waves, where the capacity plan registers an increase in headcount-adjusted engineer-sprints but the velocity forecast must apply a ramp correction to the new headcount's contribution, and the gap between the capacity plan's implied velocity increase and the velocity forecast's corrected estimate is the quantity that the roadmap plan needs to reflect.
• Technical roadmap prioritization decision record — the roadmap prioritization model determines which work the team commits to and in what sequence, while the velocity forecasting model determines when each committed item will be delivered; the two models are jointly responsible for the organization's delivery commitments, and the most common failure mode at the intersection is that the prioritization model assumes higher delivery certainty than the forecasting model can support — committing to a quarterly roadmap based on P50 velocity estimates while treating those estimates as near-certain, rather than as the median of a distribution that the team will exceed half the time and fall short of the other half; the prioritization model should incorporate the forecasting model's P70 or P90 estimates as the basis for commitment, with P50 estimates used for internal planning buffers rather than for the committed roadmap items that stakeholders will hold the team accountable to.
• Open-source extractor — sprint velocity forecasting decisions are among the decisions most frequently worked through in AI chat sessions: engineering managers use ChatGPT or Claude to reason through how to model velocity variance when committing a major feature to a board partner, how to build a learning curve adjustment model for a hiring wave that will suppress Q2 velocity below the H2 roadmap assumption, how to structure a commitment conversion protocol that stops sales teams from quoting P50 estimates as contractual delivery dates, and how to calibrate a Monte Carlo velocity model against historical sprint data when the team's composition has changed significantly in the past six months; those sessions contain the forecasting reasoning that planning tools do not preserve — what the velocity distribution actually looked like when a commitment was made, what variance sources were discussed and not yet captured in the historical data, and what the original intent of the commitment conversion protocol was before the sales team adapted it to fit their quoting workflow; running those sessions through the extractor before a planning retrospective produces the decision log that distinguishes a delivery miss caused by model calibration error from one caused by genuine demand volatility, and that distinction determines whether the corrective action is a forecasting model update or a scope negotiation.