Schrödinger's Roadmap

[🇩🇪 - Schrödingers Roadmap]

🚦 Schrödinger’s Roadmap: A Status Non-Report↑

Wednesday morning at FluxIon Grid. Dennis has finished the eighteen-month roadmap. Eleven teams. Sixty-four epics. Seventy-three coloured bars terminating in Q1 2028.

The PDF was exported from the portfolio tool on Friday. On Monday, Sarah told him the settlement-layer migration requires seven additional weeks. Dennis does not enter the slip into the roadmap. Shifting line 31 would cascade through every downstream dependency and visually prove the document is obsolete.

So he tints the bar a slightly lighter shade of green and adds “in clarification” to the comment tooltip.

The board members reviewing the diagram at 11:00 do not read tooltips. The roadmap illusion in its purest form: A plan that is simultaneously green, and not green at all. Nobody at the table believes the February 2027 date for the Smart-Settlement v3 go-live. Nobody will say so. The slide is approved, lunch arrives at noon, and the third Thursday in February 2027 will pass without surprising anyone.

Dennis files the signed PDF in the Portfolio Q4 2026 tab as a green item. Dipl.-Ing. Lehmann ticks the box. Schrödinger’s Roadmap has done its real job before it was ever drawn: It converted executive anxiety about uncertainty into the appearance of control.

📐 The Cone of Uncertainty: Why a Date at Project Start Is a Wish With a Calendar Marker↑

Barry Boehm measured the natural variance of effort estimates across real US aerospace and defense projects in Software Engineering Economics in 1981. The dataset he ran the cone against was not a thought experiment. It was the actual delivery record of dozens of military software contracts, scored against their original estimates at four defined milestones: feasibility, requirements, design, and code-complete.

The finding on page 311: at the absolute start of a non-trivial software project, with requirements unclear and architecture unbuilt, estimates show a spread of factor four in either direction.

A feature estimated at ten weeks could complete in two and a half weeks. Or in forty.

The midpoint of that range has no operational meaning, because the distribution is asymmetric. Software estimates are bounded below (you cannot deliver in negative time) and unbounded above (you can be arbitrarily late). The mechanism Boehm names is structural information starvation: at project start, the variables that drive cost (architecture, integration scope, regulatory friction, discovered defects) are unknown.

They are not poorly estimated. They are not yet visible.

The cone narrows as the project progresses. Once the architecture is fixed, the spread shrinks to factor two. Once the first vertical slice is in production, it lands near plus-or-minus 25 percent. Three weeks before delivery the date is predictable to the week. The cone narrows structurally, not because estimators get better but because the information becomes more complete.

An eighteen-month roadmap fixes a commitment at the widest end of the cone. The moment of maximum variance, labelled as the moment of maximum certainty.

🧠 The Inside View: Why Senior Estimators Underestimate Like Graduates↑

Daniel Kahneman and Amos Tversky supplied the cognitive explanation in 1979. The planning fallacy is the systematic tendency to underestimate the time and effort of future undertakings, even when the estimator can deliberately recall comparable past undertakings.

Asked when will this be done?, the brain constructs an ideal trajectory: clean requirements, green tests, friendly security review. The estimate anchors on this internal film. The memory of the last five projects, in which security review took eleven weeks, is not retrieved.

Kahneman called this the inside view. The correction, the outside view, requires ignoring the specifics of the current project and forecasting from the distribution of comparable past projects. It is rarely used because it feels defeatist.

Magnus Jørgensen reviewed dozens of empirical studies of human effort estimation in software in 2004. The consolidated finding: experts underestimate effort systematically by thirty to fifty percent. The bias does not diminish meaningfully with experience.

A senior architect with twenty years of domain expertise produces the same direction of bias as a graduate engineer in a first project.

Only the absolute spread tightens. Seniority does not buy you out of the inside view. It does pay better, though.

📉 The Multiplication Trap: How Forty Per Cent Bias Becomes One in a Thousand↑

The roadmap that the board signs consists of terms each of which is on average forty percent early, chained in a dependency graph that does not average the bias out. It multiplies it.

Sam Savage worked the mathematics in The Flaw of Averages. Take ten tasks chained in series, each with a fifty-percent probability of being on plan. The chain has a probability of one in 1,024 of being on plan end-to-end. Mean-value estimates, composed in series, produce a probability of meeting the date that vanishes long before it is conceded politically.

Now look at Dennis’s diagram again. Sixty-four epics. Cross-team dependencies on every second one. The probability that the diagram is correct as drawn is structurally indistinguishable from zero. The board does not need to be bad at maths to miss this. They need only to look at one bar at a time.

🚧 The Hit-Date Mirage: Where the Slip Actually Went↑

The natural objection from the steering committee is that some programmes hit their dates. They do, and the reading is instructive. Programmes that hit their dates fall into recognisable patterns:

• The programme was in fact small and well-understood. The cone was narrow from the start. Predicting the date was not skill. It was the absence of variance.
• The team compressed scope until the date held. Half the originally promised features quietly disappeared into the next quarter. The date is intact. Done has been redefined.
• The team supplied heroism and overtime in the final weeks that did not appear in the plan. The date held. The cost appears six months later in the burnout index, in the resignation of the architect with bus factor 1, in the ticket-bounce rate of the team that delivered.

None of this refutes the mathematics. In each case the system held the date variable constant by adjusting another variable: scope, quality, or the people. What changes between programmes is not whether physics applies. It is which variable absorbs the slip.

Schrödinger’s Roadmap hides which one.

📊 The Confidence Band: Replacing the Single Bar With a Probability Curve↑

Dan Vacanti operationalised the alternative in Actionable Agile Metrics for Predictability in 2015. The dataset Vacanti built the method on was not modelled. It was the actual ticket-throughput record of dozens of delivery teams across financial services, telco and e-commerce, sampled in weekly buckets over twelve to twenty-four months.

The mechanism: instead of asking when will these forty stories be done?, record the team’s historical throughput distribution (tickets completed per week over the last ten to twenty weeks) and sample from that distribution via Monte Carlo simulation, ten thousand possible futures.

The output is not a date. It is a probability distribution: 50 percent confidence by week eleven, 85 percent by week fourteen, 95 percent by week seventeen.

The mechanism the technique defuses is the inside view. The forecaster never has to imagine how long anything will take. They look at how long things actually have taken, and let the simulation do the chaining. The Multiplication Trap evaporates because Monte Carlo composes the variance correctly. The planning fallacy evaporates because no human imagines the future, the historical data does.

For Dennis, this means the Smart-Settlement v3 line on the slide stops reading “GO LIVE 18 February 2027” and starts reading “50 percent confidence Q1 2027, 85 percent Q2 2027, 95 percent end of Q3 2027.” Same team, same backlog, same Monday morning. Different format.

The mathematics is high-school. The discipline of measuring throughput honestly is not. Most organisations cannot run the simulation because their data is contaminated by blocked tickets that are silently re-pointed to keep individual sprints green, by epics sized through political negotiation rather than slicing, and by a Definition of Done that varies by team and by quarter. Throughput-based forecasting requires throughput-honest tickets first.

The steering committee will hate the new format the first time it lands. The single bar was a contract; the band is an admission. They learn to value the band the first time the early edge of it hits and a success can be booked that the old format would have scored as a miss.

🌊 The Rolling Wave: Why Shorter Horizons and Continuous Release Are the Only Honest Forecasts↑

In order to get valuable data that Monte Carlo is run on, two structural moves shrink the cone before the simulation runs.

The first is batch size. Don Reinertsen showed in The Principles of Product Development Flow (2009) that variance grows non-linearly with the planning horizon. A six-month commitment carries six months of accumulated unknowns. A six-week commitment carries six weeks. Total throughput is unchanged; predictability differs drastically.

Rolling-wave planning, with the next quarter binding and the quarters after as direction, is the honest acknowledgement that the cone narrows on closer approach. The next quarter sits inside the narrow end of the cone. The third quarter out does not.

The second is the release architecture. Jez Humble and Dave Farley argue in Continuous Delivery (2010) for separating the technical deployment of code from its functional activation. Code goes to production continuously, gated by feature flags. Functional activation is a configuration change, not a deployment.

The variance that tortured the roadmap collapses, because the commitment now refers to a low-variance event (flipping a flag) rather than a high-variance event (integrating, regression-testing and shipping on a Tuesday).

A decade of DORA research documents the consequence: teams that deploy on demand have change lead times under a day. Teams that batch into quarterly releases need one to six months for the same change. Roadmap variance is a property of the release architecture, not of the work. If your bars are eighteen months long, your release architecture is the reason. The work itself does not require it.

For the practitioner, two artefacts change next Monday:

• The portfolio review stops accepting any commitment longer than the next quarter as binding. Bars beyond it are colour-coded as direction, not as date.
• The release calendar is decoupled from the deployment calendar. Marketing books an activation date. Engineering ships continuously into production behind a flag, weeks earlier.

🪑 The Signature Asymmetry: Who Signs the Date and Who Delivers It↑

The roadmap as ratified document is also a power artefact. The signature on the bottom of the slide belongs to the executive board. The probability of meeting the date belongs to a team three layers down whose throughput data the board has never seen. The room with the authority to fix the date is structurally separated from the room with the information about whether the date is real.

Read the configuration in the language of the Four Roles and Five Powers. HR-Legitimate authority and the disciplinary contract sit at the executive table. Architecture-Legitimate authority and the empirical throughput data sit with the team.

Between them stands a Proxy-PO whose mandate is roadmap upkeep and whose performance review depends on the roadmap looking managed. Dennis is not lying when he tints the bar a lighter shade of green. He is reporting against the only metric his role exists to optimise.

The information asymmetry is structural, not personal. The board sees one number per epic per quarter. The team sees the throughput distribution week by week. Schrödinger’s Roadmap is the artefact that converts the second view into the first one, and discards the variance in the conversion. Replacing the single bar with a confidence band is not a forecasting reform. It is a small redistribution of decision rights: the board gets a worse-looking diagram and a better-calibrated commitment.

That trade is the work. The mathematics is the easy part.

⚠️ The Anchor Migration: When the 85th Percentile Becomes the New Deadline↑

Probabilistic forecasting has a predictable failure mode and the practitioner should name it before the steering committee discovers it on its own.

The failure mode is anchor migration. The first quarter of running confidence bands, the board reads 50 percent / 85 percent / 95 percent and treats them as the bands they are. Around the third quarter, somebody in the room asks the obvious question: which of the three numbers is the commitment? The team, under pressure, answers the 85th percentile. From that quarter on, the 85th percentile is a deadline. The 50th vanishes from the slide. The 95th becomes a buffer that is mentally already spent.

The planning fallacy has migrated up one layer of abstraction. The single bar is back. Only the label has changed.

The structural defence is to keep all three bands on the slide every quarter, to hold the team accountable for the shape of its throughput distribution rather than for the 85th-percentile date, and to refuse, as a coach, to let the format collapse to a single number. The defence is harder than running the simulation. The simulation is mechanics. The discipline of leaving uncertainty visible quarter after quarter is governance.

Vacanti’s lever cuts. The lever can be picked up by the wrong end. Two things can be true at the same time.

🏁 The Bottom Line: A Plan Is a Distribution, Not a Date↑

The deeper structural fix is Beyond Budgeting in Bjarte Bogsnes’s sense: decouple target, forecast and resource allocation rather than bundle them into the annual budget. That is a multi-year CFO move which most engineering organisations cannot trigger themselves.

What an engineering organisation can trigger itself, next Monday:

• Replace the single date with a confidence band sourced from the team’s actual throughput distribution. No imagination, no inside view.
• Bind only the next quarter. Treat anything beyond as direction.
• Decouple deployment from release with feature flags. Move the high-variance event off the calendar that the board reads.
• Leave all three bands visible every quarter. The moment the slide collapses to one number, the mathematics has been undone.

Schrödinger’s Roadmap survives because it lets the board feel in control without having to look at the data underneath. The confidence band makes the data the artefact. That is uncomfortable, which is the same thing as honest.

Boehm published in 1981. Kahneman published in 1979. Vacanti published in 2015. None of this is news. The fact that it is still news in your boardroom is the actual finding.

⏱️ TL;DR: A Date Is a Wish, a Distribution Is a Plan↑

For the executive who has six minutes between two steering committees:

• The roadmap is signed at maximum uncertainty. Boehm’s cone has a factor-four spread at project start. An eighteen-month single date is mathematically a wish with a calendar marker.
• Seniority does not fix the inside view. Jørgensen’s review of expert estimation: thirty to fifty percent systematic underestimation, independent of experience. The bias is structural, not skill.
• Mean-value estimates multiply, not average. Ten chained 50-percent steps land at one in a thousand. Your sixty-four-epic Gantt is structurally indistinguishable from zero probability of being right as drawn.
• Programmes that hit dates are usually small, scope-cut, or paid in burnout. The variable absorbing the slip is just hidden somewhere off the diagram.
• Replace the single bar with a confidence band. Monte Carlo simulations against actual throughput. Three numbers per epic per quarter, not one.
• Shorten the horizon and decouple deployment from release. Bind the next quarter. Ship continuously behind feature flags. Marketing chooses the activation date, engineering chooses the deployment date.
• Watch the 85th percentile become the new deadline. The lever has a predictable failure mode. Keep all three bands on the slide every quarter or the planning fallacy migrates one layer up.

🧾 The Receipts: The Mathematics and the History↑

If your steering committee insists the eighteen-month Gantt is a contract, put these on the table.

• Boehm, B. (1981). Software Engineering Economics (ISBN 978-0138221225). The original cone-of-uncertainty data, against TRW’s contract record at four defined milestones. The mathematical proof that variance shrinks structurally with information, not with skill.
• Bossavit, L. (2015). The Leprechauns of Software Engineering (ISBN 978-2954745503). The critical re-examination of the popular cone numbers. Useful as the calibration check before you cite Boehm in a hostile room.
• Kahneman, D., & Tversky, A. (1979). “Intuitive Prediction: Biases and Corrective Procedures.” TIMS Studies in Management Sciences, 12, 313–327. The original planning-fallacy paper. The inside-view / outside-view distinction lives here.
• Kahneman, D. (2011). Thinking, Fast and Slow (ISBN 978-0374533557). The popular synthesis. The inside-view chapter is the one to put in front of the board.
• Jørgensen, M. (2004). “A review of studies on expert estimation of software development effort.” Journal of Systems and Software, 70(1–2), 37–60. The empirical proof that thirty to fifty percent underestimation is independent of seniority. The reason “we will have our most senior architect estimate it” is not a defence.
• Savage, S. L. (2009). The Flaw of Averages ( ISBN 978-1118073759). The mathematics of mean-value composition. The reason a sixty-four-epic Gantt is not a one-in-two coin flip.
• Vacanti, D. S. (2015). Actionable Agile Metrics for Predictability (ISBN 978-0986436338). The throughput-based forecasting method described above, end-to-end, with worked Monte Carlo examples. The single most important practitioner reference for the lever.
• Reinertsen, D. G. (2009). The Principles of Product Development Flow (ISBN 978-1935401001). The non-linear variance-with-batch-size argument. The structural justification for binding only the next quarter.
• Humble, J., & Farley, D. (2010). Continuous Delivery (ISBN 978-0321601919). The original deployment / release decoupling text. The reason the high-variance event does not have to live on the board’s calendar.
• Bogsnes, B. (2016). Implementing Beyond Budgeting, 2nd ed. (ISBN 978-1119152477). The structural root of the annual roadmap. The reform the engineering organisation cannot trigger but should be able to name.
• Google Cloud (2024). Accelerate State of DevOps Report 2024. https://dora.dev/research/2024/dora-report/. The longitudinal evidence that change-lead-time is a property of the release architecture, not of the work.