The technical roadmap process decision record: why the planning horizon you chose determines your commitment surface and your scope creep failure mode

A 26-person SaaS that built compliance infrastructure for mid-market financial services companies had been running its roadmap process since the founding session in year one. The process had been established by the three-person founding team in a single planning conversation: they would plan in six-month increments, commit features to the roadmap based on their collective estimate of what was buildable in that window, and update customers on delivery progress at the quarterly business review. For the first eighteen months, the process worked. The founding team estimated features collectively, each member had deep context across the entire codebase, and their velocity was consistent enough that six-month commitments were reliably honored within a two-to-three-week margin.

By the end of year two, the team had grown to twenty-six engineers. The founding engineers had moved into senior roles and were no longer the primary contributors to most active subsystems. Feature estimation was done in sprint planning sessions with the relevant team, which had variable familiarity with the affected codebase areas. The codebase had grown from the founding team's coherent monolith into a service-oriented architecture that had developed organically as the team had grown — not by design, but by the natural tendency of growing teams to build new capabilities in new services rather than extending the existing ones they did not fully understand. Cross-service dependencies were common and frequently underestimated in planning, because the engineers estimating a feature's complexity were specialists in the service they were building and had limited visibility into the integration cost with the services they depended on.

In month twenty-eight, the head of sales closed a contract with a large regional bank. The contract included a commitment — documented in the agreement's technical appendix — to deliver a compliance reporting module with FDIC call report extraction by week twelve of the engagement. The commitment was reviewed in a planning session before the contract was signed. The engineering team estimated the module at sixty story points, which at the team's current velocity of twelve points per sprint (two weeks) represented five sprints, or ten weeks of work — with two weeks of buffer before the twelve-week deadline. The estimate was made by the team that owned the compliance reporting service, based on their understanding of what the module required and their familiarity with the FDIC call report data structure.

What the estimate did not account for was that the FDIC call report extraction required integration with three internal data pipeline services that the compliance reporting team had not previously integrated with. The integration work was not represented in the story points — it was a dependency, not a task, and dependencies were typically surfaced during sprint planning, not during commitment planning. When the integration work became visible during the first sprint, it added approximately forty points of additional work — work that was not in the original estimate, would compete with the original estimate for the compliance team's capacity, and could not be fully parallelized because the integration design decisions required inputs that could not be finalized until the first integration service's interface contract was validated.

In week ten, the module was approximately forty percent complete. The team had delivered the data model, the basic extraction logic for the most common call report schedules, and the API interface the frontend would call. The FDIC-specific schedule extraction — which was the most complex and most contractually material part of the module — was behind the original timeline by six weeks. The customer's contract renewal conversation, which had been scheduled for week eleven on the assumption that the compliance module would be in acceptance testing, was conducted with an incomplete module and a revised delivery estimate of week twenty. The customer's procurement team initiated a review of the SLA terms. The legal remediation process took three months and involved a contract amendment, a fee concession, and the assignment of a dedicated support engineer for the duration of the delay.

The engineers who built the original estimate were not negligent. They estimated the work they could see — the compliance reporting service work, based on their familiarity with that service's codebase — and did not systematically estimate the integration work they could not fully characterize at the time of commitment. The planning process had not specified a protocol for estimating cross-service integration cost at the commitment planning stage, because at founding, cross-service integration was rare and the founding team's full-stack context made integration cost visible to the estimators as implicit knowledge. At twenty-six engineers, across a service-oriented architecture with significant cross-service dependency density, integration cost was the largest single source of estimation error — and the founding planning process had no mechanism for surfacing it before a commitment was made.

A 34-person product SaaS that built event management software had been running story-point estimation since its founding. The founding session had established the process clearly: the team would estimate user stories in story points using a modified Fibonacci scale, maintain a running velocity baseline from the last four completed sprints, and use that velocity to forecast sprint capacity for the next planning session. The process was well-understood, well-documented in the team's Confluence, and had worked reliably through the first two years. The founding team's four engineers had calibrated story points together, developing a shared intuitive reference set — a one-point story was something any team member could complete alone in half a day without looking at new code; a five-point story required a day or two and some exploration; a thirteen-point story was something no one had done before that would require design decisions during implementation.

By year three, the team had grown to thirty-four engineers across four product areas. Each product area ran its own sprint planning and maintained its own velocity baseline. The shared reference set — the calibrated intuition the founding team had developed together — had not been explicitly carried forward to the new engineers or validated across the new teams. Story points had become a local artifact within each product area, calibrated to that team's specific familiarity with their own subsystem and their own interpretation of the founding Fibonacci scale. A five-point story in the events team was not the same quantity of work as a five-point story in the payments team, which was not the same as a five-point story in the integrations team. The velocity baselines were calculated per team and used for per-team forecasting — which meant the cross-team dependency work that increasingly connected the four product areas was not reflected in any team's velocity baseline, because it appeared as overhead rather than as story points in the teams that absorbed it.

The quarterly planning process aggregated the four teams' forecasts into a product roadmap commitment that the head of product presented to the board and communicated to enterprise customers. At the end of each quarter, the roadmap team conducted a retrospective against the planned delivery. The pattern over the preceding six quarters was consistent: the team delivered between sixty and seventy percent of the planned scope, with the undelivered scope pushed to the following quarter. The post-quarter retrospectives consistently attributed the gap to "planning uncertainty," "unexpected technical complexity," and "cross-team dependencies that weren't visible at planning time." Each retrospective produced an action item to "improve estimation accuracy," which in practice meant holding more refinement sessions before committing stories to the sprint plan — but the refinement sessions did not address the structural gap: that the velocity baselines being used to forecast capacity were calculated from a sample of work that systematically excluded the cross-team dependency overhead that was consuming between twenty and thirty-five percent of each team's actual delivery capacity.

The practical consequences accumulated over eighteen months of consistent misses. The sales team learned to apply a private correction factor to the engineering team's roadmap commitments when setting customer expectations, discounting timeline estimates by thirty percent before communicating them. The product team began adding buffer to roadmap items by artificially extending the planned sprint count — which further degraded the velocity baseline accuracy, because the baseline was now calculated from sprints where part of the planned work had been deliberately padded. Enterprise customers who had entered renewal cycles with roadmap commitments that were not delivered on time received a consistent explanation — "engineering is complex and hard to predict" — without a structural change to the estimation process that would produce different results in the next quarter. Three customers in the same quarter escalated roadmap delivery concerns to their account executives, each independently. The account executive team's response was to request that engineering provide more "conservative" estimates — which in the absence of a structural fix to the velocity baseline and the cross-team dependency accounting produced the same outcome with a longer stated timeline rather than a shorter stated timeline, without changing the actual delivery rate.

The founding session that established the story-point process had not specified a recalibration trigger — a condition under which the velocity baseline inputs, the story-point reference set, or the cross-team dependency accounting would be formally reviewed and updated. It had not specified that the reference set needed to be validated across teams as new engineers joined and the team structure evolved. It had not specified that cross-team dependency work needed to be represented in the capacity model rather than absorbed as overhead. These omissions were invisible in year one, when all four future team areas were worked on by the same four engineers who had developed the shared calibration together. They became load-bearing as the team grew, and they produced a planning system that had the structural form of rigorous estimation — Fibonacci points, four-sprint velocity baselines, quarterly planning sessions with refinement — without the calibration accuracy that makes the structure produce reliable forecasts.

A 41-person B2B SaaS that built procurement workflow software had established its roadmap communication process in the early customer-facing years, when the board met quarterly and the natural cadence for roadmap updates was one per board meeting. The process was documented: engineering would prepare a roadmap update presentation for each board meeting, the head of product would include a customer-facing roadmap summary in the quarterly customer newsletter, and account executives would use the quarterly roadmap summary in renewal conversations. Between quarterly updates, the roadmap was treated as stable — changes to the delivery timeline or scope were tracked internally in Jira but were not surfaced to customers or the board until the next quarterly update.

The rationale for the quarterly-only communication cadence had been reasonable at founding: the founding team was small enough that the board could verify the roadmap directly with the engineers, customers were early adopters who understood that roadmaps were directional rather than contractual, and the quarterly cadence matched the board's governance rhythm. By year three, with forty-one engineers, thirty-two enterprise customers with contractual SLA terms, and a board that was receiving the quarterly roadmap update as the primary source of engineering delivery information, the rationale had not been revisited.

In the third year's Q2, two significant scope changes developed in the six weeks between the Q1 board meeting and the Q2 board meeting. The first was a technical discovery: the procurement workflow module's integration with SAP — the most commonly requested enterprise integration — required a custom middleware layer that had not been anticipated in the original estimate because the SAP connector the team had planned to use had been deprecated in a version the customers were running. The middleware layer added approximately eight weeks of engineering work. The second was a product decision: the head of product, in response to a cluster of customer feedback, made a decision to prioritize the SAP integration middleware work over two other roadmap items — a reporting dashboard enhancement and a mobile approval flow — that had been committed to in the Q1 roadmap. The scope reduction of the two deprioritized features was tracked in Jira and communicated internally, but was not surfaced to customers or the board until the Q2 update.

The Q2 board meeting occurred in week fourteen of the quarter. Three enterprise renewal conversations had happened in weeks ten through thirteen. In each renewal conversation, the account executive had used the Q1 roadmap — the most recent customer-facing version — as the basis for the feature commitments cited in the renewal proposal. Two of the three customers had signed renewal contracts with references to the reporting dashboard enhancement as a committed delivery in Q3. One customer had referenced the mobile approval flow in the same context. All three were large customers whose contract terms included a vendor commitment to deliver the referenced features within the renewal period as a condition of the renewal pricing.

At the Q2 board meeting, the engineering team surfaced the scope change: the SAP middleware work was consuming the capacity that had been allocated to the reporting dashboard enhancement and the mobile approval flow, which were now pushed to Q4 at the earliest. The board's question was straightforward: had any renewal contracts been signed against the Q1 roadmap commitments in the interim? The answer was yes. The legal and account management process that followed involved renegotiating three contracts, a pricing concession on one renewal that the customer used the scope change as leverage for, and an internal process review that identified the quarterly-only communication cadence as the root cause — not the scope change itself, which was reasonable, but the ninety-day window between the scope change decision and its communication to the customers who were actively making contractual decisions against the original commitment.

The founding session that established the quarterly communication cadence had not specified a trigger condition for an out-of-cycle update when delivery state diverged materially from the published roadmap. It had not specified a process for reviewing the current published roadmap against the internal delivery state before a renewal conversation was conducted. It had not specified that account executives were responsible for confirming that the roadmap items they referenced in renewal proposals were still on the current internal roadmap before citing them. All three omissions were harmless at founding, when the team was small, the customer base was tolerant of roadmap variability, and the board had direct access to the engineers who could confirm delivery state in real time. In year three, the same omissions produced a ninety-day commitment gap with contractual consequences.

Structural properties set by the technical roadmap process decision

Three structural properties are determined when a team decides its planning horizon, its estimation model, and its stakeholder communication cadence. None are explicitly labeled in the founding planning session — they are operational characteristics that emerge from the assumptions the founding process embeds about team size, estimation accuracy, and how commitments flow from engineering to customers.

Property 1: The planning horizon and the commitment surface. The planning horizon is the distance ahead at which the team makes commitments that customers, investors, and internal stakeholders treat as promises — not directional intent, but operational plans against which they make their own decisions. The commitment surface is the total area of downstream decisions being made against the team's roadmap commitments at any given moment: customer contracts being negotiated, investor communications being prepared, sales conversations being conducted, integration investments being made by customers based on expected feature delivery dates. The commitment surface grows as the planning horizon extends and as the customer base and investor base grow — more stakeholders are making more decisions against a longer-range set of commitments. The failure mode is a commitment surface that exceeds the team's reliable delivery window: the team is making promises that are being treated as plans by stakeholders who are taking non-reversible actions against them, while the team's actual delivery reliability at the commitment horizon length is materially lower than its reliability at shorter horizon lengths. The founding team's reliable delivery window — the distance ahead at which they could commit with high confidence based on their full-context estimation — is not the team's reliable delivery window at two or three times the headcount, at an order-of-magnitude more codebase complexity, and with significant cross-team dependency overhead. A planning horizon policy that distinguishes between the commitment horizon (the distance ahead at which commitments can be made with customer-facing implications) and the vision horizon (the distance ahead at which direction can be communicated without commitment) limits the commitment surface to the range where the team's estimation accuracy is empirically reliable. The engineering team growth decision record connects here: team growth changes the delivery capacity model, the cross-team dependency density, and the estimation accuracy profile simultaneously — a planning horizon calibrated to the founding team's delivery reliability needs to be recalibrated when the team composition changes materially.

Property 2: The estimation model and the scope creep failure mode. The estimation model is the mechanism that connects delivery capacity to roadmap commitments — it translates "what we want to build in the next quarter" into "what we can commit to delivering in the next quarter" by applying a capacity model to the planned scope. An estimation model calibrated to a founding team's shared intuition degrades in accuracy as the team grows in two distinct ways. The first is calibration drift: story points estimated by a four-person team where every engineer has read every line of code do not mean the same thing as story points estimated by twenty engineers across three separate subsystems with variable familiarity — the reference set, the unit of the estimation system, loses its shared meaning as the team grows past the size where shared calibration is maintained through daily interaction. The second is systematic exclusion: founding estimation models typically measure the complexity of the work the team is doing within its own area of ownership, and exclude or significantly underweight the overhead of cross-team dependency coordination — integration negotiation, API contract alignment, integration testing, deployment ordering — that grows as the team structure becomes more complex. The scope creep failure mode develops not because engineers underestimate their own work, but because the estimation model excludes a growing category of work that is consuming capacity without being represented in the velocity baseline. A capacity buffer for cross-team dependency work — a fixed percentage of each sprint's capacity reserved for integration overhead, maintained separately from the story point budget — is the mechanism that closes the gap between the capacity the model predicts is available and the capacity that is actually available for story-pointed work after cross-team coordination obligations are met. The technical debt decision record connects here: technical debt remediation competes with new feature work for the same capacity budget, and a planning process that does not explicitly allocate capacity for technical debt work will systematically under-plan that work until a debt incident forces an emergency allocation that displaces committed new feature work.

Property 3: The stakeholder communication cadence and the expectation gap surface. The communication cadence determines how quickly a divergence between the published roadmap and the actual delivery state becomes visible to the stakeholders who are making downstream decisions against the published roadmap. A cadence set to match a governance cycle — quarterly board meetings, annual customer reviews — rather than the delivery cadence produces a window in which the expectation gap can grow unchecked. Customers sign contracts against commitments. Investors communicate roadmap items to their portfolios. Sales teams close deals against feature promises. Each of these actions is a non-reversible commitment made by a stakeholder against the team's published roadmap. When a scope change or timeline change occurs, the stakeholders who have not yet received the updated roadmap continue to make non-reversible commitments against the stale version. The expectation gap surface is the total volume of non-reversible commitments made against a stale roadmap between the internal decision to change scope and the external communication of that change. It grows as a function of (communication cadence gap length) × (stakeholder decision activity rate). An out-of-cycle update trigger — a specified threshold at which a material roadmap change requires a customer-facing communication before the next scheduled update — limits the expectation gap surface to what accumulates in the days between the internal decision and the triggered communication, rather than the weeks or months between the decision and the next scheduled cadence update. The threshold for what constitutes a material change requiring out-of-cycle communication should be defined in the founding ADR: a timeline change greater than two weeks for a committed customer-facing feature, or any scope reduction that removes a feature cited in an active sales or renewal proposal. The incident response playbook decision record connects here: the postmortem process for a missed customer commitment should include a review of whether the communication cadence produced a window in which the expectation gap grew before it was addressed — and whether the out-of-cycle update trigger, if specified, fired correctly.

What the founding session records and what it omits

The founding roadmap session — a planning conversation among the three or four founders about how long the planning horizon should be, how to estimate features, and how to communicate the roadmap to customers — records the horizon length, the estimation unit (story points, T-shirt sizes, no estimates), and the communication format. What it does not record is the cross-team dependency accounting that the estimation model requires as the team grows, the recalibration trigger that fires when estimation accuracy falls below an acceptable threshold, the out-of-cycle update condition that limits the expectation gap surface, or the distinction between the commitment horizon and the vision horizon.

These omissions are identical in structure to the rest of the founding decisions in this series: they are benign at founding, when the team is small enough that the omissions are covered by shared context. A planning horizon that extends further than the team's reliable delivery window is not a problem when the founding team's reliable delivery window extends to the full planning horizon — which it does when the team is small, the codebase is simple, and every engineer has full-context estimation accuracy. A calibration drift in the story point system is not a problem when all four engineers share the same calibration reference every day — which they do when they are working on the same codebase in the same room. A quarterly communication cadence that creates a ninety-day gap is not a problem when the customer base is small enough that the founders can inform each customer directly the day a scope change is made.

The failure modes develop at predictably different rates. The commitment surface failure develops from the first customer commitment made against an estimation that did not include cross-team integration cost — which is typically the first customer commitment made after the team structure has grown from one team to two or three. The scope creep failure develops from the first quarter in which cross-team dependency overhead exceeds ten to fifteen percent of total capacity — which typically happens within eighteen to twenty-four months of reaching ten or more engineers across two or more product areas. The expectation gap failure develops from the first scope change that happens mid-quarter in a team with a quarterly communication cadence and a customer base large enough that sales and renewal conversations are happening continuously rather than at scheduled intervals — which typically emerges in year two or three.

The technical roadmap ADR closes these gaps by documenting the planning horizon policy, the estimation model with its cross-team capacity buffer, the out-of-cycle communication trigger, and the recalibration conditions at the time the planning process is designed — not after each failure mode has produced a contract dispute, a sustained forecasting miss, or an expectation gap that required legal remediation. The decisions never written down in the roadmap domain are not the horizon length or the estimation unit — those appear in the planning process documentation and the sprint tooling configuration. They are the cross-team dependency overhead model, the estimation recalibration trigger, the distinction between the commitment horizon and the vision horizon, and the material change threshold that fires an out-of-cycle stakeholder communication. The new CTO onboarding problem is specific in the roadmap context: the incoming technical leader finds the roadmap in the planning tool, the velocity charts in the sprint tool, and the customer-facing roadmap in the product deck — but cannot determine whether the velocity baseline accounts for cross-team dependency overhead, whether the planning horizon has been calibrated against the team's demonstrated forecast accuracy at that horizon length, whether there is a process for communicating material scope changes out-of-cycle, or whether the current roadmap represents the team's actual delivery commitments or an optimistic projection that has been informally discounted by the sales team and the account executives. The roadmap ADR makes those decisions explicit and auditable. The WhyChose extractor finds the roadmap process discussions in your AI session history — the conversation where the founding team set the planning horizon, decided how to estimate, built the first quarterly roadmap, or made the first commitment to a customer against an estimated timeline — and surfaces those parameters so you can assess which assumptions still hold and which have been superseded by the team and product growth that has happened since the founding planning session.

The technical roadmap process ADR: five sections

Section 1: Planning horizon policy and commitment classification. Specify the maximum planning horizon for commitments with customer-facing or investor-facing implications, the mechanism for calibrating the horizon to the team's demonstrated forecast accuracy, and the distinction between the commitment horizon and the vision horizon. The commitment horizon is the distance ahead at which the team makes specific, date-bounded delivery commitments — the commitments that go into customer contracts, renewal proposals, investor communications, and sales conversations as promised delivery dates. The vision horizon is the distance ahead at which the team communicates directional intent without date-bounded commitment — the features that are on the roadmap as planned work, presented to customers as anticipated delivery without a specific date guarantee. Specify the criteria for placing a roadmap item in the commitment category versus the vision category: items are in the commitment category only when the work is fully scoped, the cross-team dependencies are identified and the dependency team has confirmed capacity, the estimate has been reviewed against the team's forecast accuracy baseline, and the delivery date includes a minimum fifteen percent buffer against the point estimate. Items that do not meet all four criteria are in the vision category until they do. Specify the recalibration trigger for the horizon length: if the team's commitment-category forecast accuracy over the most recent two quarters falls below seventy-five percent (delivering the committed scope within the committed timeline), the commitment horizon shortens by four weeks and a planning retrospective is required before the horizon is extended again. Document the founding calibration: the horizon length chosen, the forecast accuracy data it was based on, and the assumptions about team size, codebase complexity, and cross-team dependency density that the horizon reflects — so that future recalibrations are evaluated against a known starting point rather than against an undocumented assumption.

Section 2: Estimation model and cross-team capacity buffer. Specify the estimation unit, the velocity measurement method, the cross-team dependency capacity buffer, and the recalibration protocol for when the model's accuracy degrades. Estimation unit: specify whether the team uses story points, ideal days, or a no-estimate approach, and document the reference calibration — the examples that define what each point value represents in concrete, verifiable terms rather than abstract complexity descriptions. A five-point story is a story that the team's historical data shows requires two to four days of engineering time for an engineer with working familiarity with the affected subsystem — not a story that "feels medium complex." The reference calibration must be reviewed and re-validated across teams when the team structure changes materially (new team formed, team merged, significant new engineer cohort added). Velocity baseline: calculate velocity as the average story points delivered per sprint over the last four sprints, excluding sprints that contained significant anomalies (company offsites, major incidents, planned low-sprint capacity weeks). Cross-team dependency buffer: reserve a fixed percentage of each sprint's capacity — starting at fifteen percent, adjusted based on observed dependency overhead from the previous quarter — for cross-team integration work that does not appear in the story point estimate but consumes engineering time (API contract negotiations, integration testing, deployment coordination, dependency-related design reviews). This buffer is not available for story-pointed work; it is explicitly reserved for the overhead that the velocity baseline excludes by design. Recalibration trigger: if actual sprint delivery falls below forecast by more than twenty percent for three or more consecutive sprints, the estimation model is formally reviewed — not the engineers, not the sprint planning process, the model inputs: the reference calibration, the velocity baseline calculation, and the cross-team dependency buffer percentage. Document the founding calibration baseline: the team size, the codebase complexity level, the cross-team dependency density, and the forecast accuracy observed over the first four to six sprints — so that recalibrations have a documented starting point to measure deviation from.

Section 3: Scope change protocol and customer impact assessment. Specify the process for evaluating requests to add scope to an in-flight quarter, the authority levels for approving scope additions, and the customer communication requirement when a scope change affects a committed delivery item. Scope addition protocol: any scope addition to an in-flight quarter must include a written assessment of which committed items will be deprioritized or delayed to make capacity available for the addition — scope is not added without scope being removed or delayed. The authority level for approving a scope change depends on its customer impact: scope changes that do not affect any committed customer-facing delivery date are approved by the engineering lead and the product lead jointly; scope changes that push a committed customer-facing delivery date by two weeks or less are approved by the head of product with customer success notification; scope changes that push a committed customer-facing delivery date by more than two weeks require executive approval and a customer communication plan before the change is approved. Scope reduction protocol: when a scope reduction or timeline extension affects a roadmap item that has been cited in an active sales proposal, renewal conversation, or signed contract, the scope change triggers a mandatory account review before the scope change is finalized — not after. The account review determines whether the customer needs to be notified before their next decision point (contract signing, integration investment, renewal close) and what the notification should contain. The scope change is not finalized until the account review is complete and the notification plan, if required, is approved. Document the criteria for what constitutes a material scope change requiring the full scope change protocol versus a minor change that can be handled within the team without customer-facing review: a material change is any change that moves a committed customer-facing delivery date by two or more weeks, removes a feature that has been cited by name in a customer communication, or changes the scope of a feature in a way that affects the feature's primary use case.

Section 4: Stakeholder communication cadence and out-of-cycle update trigger. Specify the scheduled roadmap communication cadence for each stakeholder audience, the format and content requirements for each audience, and the out-of-cycle update trigger that fires when a material change requires communication before the next scheduled update. Scheduled cadence: customers receive a roadmap update at the beginning of each quarter — a concise summary of what was delivered in the previous quarter against the committed items, what is committed for the current quarter, and what is in the vision horizon for the following two quarters with explicit language that vision items are directional, not committed. The board receives the same update in the board meeting format with the addition of the delivery accuracy metric — what percentage of the previous quarter's committed scope was delivered within the committed timeline. Internal stakeholders (sales, account management) receive a monthly roadmap update that includes the current internal delivery state — not just the committed external roadmap, but the team's current confidence level for each committed item and any internal flags that have been raised about timeline risk. Out-of-cycle update trigger: a material scope change — as defined in Section 3 — that affects a committed customer-facing item triggers a customer communication within five business days of the change decision, regardless of where it falls in the scheduled communication cadence. The communication includes: what was committed, what has changed and why, what the revised commitment is, and what options the customer has if the change affects their plans. Account executives are notified on the day of the scope change decision, before the customer communication, so that they can manage the customer relationship context. The trigger fires for the affected customers, not for all customers — a scope change that affects one customer's committed delivery does not require a communication to all customers, only to the customers whose commitments are affected. Specify who is responsible for triggering the out-of-cycle communication: the product lead is responsible for identifying which customers are affected by a material scope change, and the account executive for each affected customer is responsible for the customer communication, supported by the product lead with written context for the communication.

Section 5: Roadmap accuracy retrospective and recalibration cadence. Specify the mechanism for auditing roadmap accuracy over time and recalibrating the planning process when the accuracy falls below acceptable thresholds. The retrospective has three components. First, quarterly delivery accuracy audit: at the end of each quarter, calculate the commitment category delivery accuracy — the percentage of committed items that were delivered within the committed timeline. Calculate this separately for items with and without customer-facing delivery commitments. Review the items that missed the timeline and classify each miss by cause: estimation error (the estimate was wrong relative to the actual work required), scope addition (in-quarter scope was added without corresponding scope removal), cross-team dependency delay (a dependency team did not deliver what was needed within the timeline), or external event (an incident, a critical customer escalation, or an infrastructure failure consumed capacity not accounted for in the buffer). The classification determines the remediation: estimation error triggers an estimation model review; scope addition without offset triggers a scope change protocol review; cross-team dependency delay triggers a dependency planning protocol review. Second, estimation model calibration review: twice per year, review the estimation model inputs against the observed delivery data from the preceding two quarters — the reference calibration, the velocity baseline calculation method, and the cross-team dependency buffer percentage. Update inputs that are systematically miscalibrated rather than continuing to rationalize misses as planning uncertainty. Third, horizon length validation: once per year, validate the commitment horizon length against the team's demonstrated forecast accuracy at that horizon length. If the team is consistently delivering seventy-five percent or more of committed scope within the committed timeline, the horizon length is validated. If delivery accuracy is below seventy-five percent for two consecutive quarters, the horizon shortens per the trigger defined in Section 1 and the recalibration retrospective must identify whether the cause is estimation model miscalibration, scope change protocol non-compliance, or a planning horizon that has grown past the team's reliable delivery window as the team and codebase have scaled. Connect the annual recalibration to the engineering team growth decision record's annual review — changes in team size and structure are the primary driver of planning horizon and estimation model recalibration requirements, and reviewing both in the same session ensures the planning process is updated when the team context it was calibrated for has changed.

FAQ