Chapter 23 — Estimation in an ODUI World

Estimation quietly sits underneath budgets, roadmaps, contracts, and strategic bets. When it goes wrong, it doesn’t just hurt a sprint — it distorts trust, planning, and strategy.

ODUI does not remove estimation. It puts it back in its proper place:

Estimation supports decisions. It must never drive them.

This chapter shows how to keep estimation honest, lightweight, and compatible with ODUI, so it becomes a strategic asset instead of a source of pressure and blame.

Important note (because this gets confused constantly):

Time estimation = effort in hours / days (for example MDW = man‑days of work).
Delivery date = a calendar prediction that depends on capacity, sequencing, interruptions, and dependencies.

ODUI uses time estimation only after bucket allocation and prioritisation are done. A time estimate helps you understand cost. It does not magically create a delivery date.

23.1 Why Estimation Matters More Than Most Companies Admit

Most teams treat estimation as a local concern:

“How many points is this?”
“Is this a 2‑day or 5‑day task?”

But behind the scenes, these numbers quietly shape:

annual budgets and headcount
product roadmaps and contract commitments
revenue forecasts and portfolio strategy

Rough guesses from planning sessions become:

promised dates in sales decks
solid numbers in financial models
expectations baked into leadership reviews

When those guesses drift, plans don’t just slip — relationships erode.

Bad estimation doesn’t just break plans — it breaks trust.

The Emotional Load Behind the Numbers

Estimation looks numeric but it is deeply emotional.

Teams fear that if they:

estimate high → they look slow
estimate low → they’ll be blamed for slips
admit uncertainty → they’ll look unprofessional

Leaders fear that if they:

present uncertainty → they’ll look weak
avoid hard dates → they’ll lose influence or budget
revise estimates → they’ll damage credibility

So everyone colludes in a quiet fiction: numbers are presented as precise, risk is downplayed, uncertainty is hidden.

ODUI doesn’t pretend that fiction is sustainable. It reframes estimation so it can be honest — without wrecking strategy or culture.

Where Estimation Touches ODUI

Estimation is there even when you don’t call it out:

B1 — how long we’ll be disrupted
B2 — how far we can move a KPI this quarter
B3 — whether we can meet an obligation by a date
B4 — how much exploration we can safely handle

At a higher level it informs:

capacity and scenario planning
portfolio selection and pacing
multi‑quarter strategic bets

You cannot separate ODUI from estimation. You can only decide how explicitly and how safely you handle it.

Why We Waited Until Now

Earlier chapters set the foundations:

What matters? (outcomes and KPIs)
What kind of work is it? (B1–B4)
How much capacity do we have? (bucket mix)

Only then comes:

How big is this? (estimation)

Estimation without outcome clarity is just sophisticated guessing.

Now that ODUI is established, we can add estimation without letting it quietly run the company.

23.2 Why Traditional Estimation Fails

Most organisations think their estimation problems come from bad techniques or undisciplined teams. In reality, estimation fails because the environment around it makes accuracy impossible.

Asked Too Early, With Too Little Clarity

The classic pattern:

“Give me an estimate so we can decide if we should do this.”

Teams are forced to estimate solutions before:

the problem is clear
outcomes and KPIs are defined
constraints and trade‑offs are understood
bucket classification is agreed

So they guess — and the guess becomes a plan.

Estimates Turned Into Commitments

Estimates are offered as ranges and probabilities, but they are interpreted as:

promises
deadlines
contract terms

Teams start padding to stay safe. Leaders treat padded numbers as truth. When reality hits, everyone feels betrayed. Trust collapses, and honesty is punished.

No Capacity Context

Many organisations estimate work before asking the most important question:

“Do we even have room for this?”

Without a clear view of B1, B2, B3, B4 capacity, estimation is just noise layered on top of overload.

Risk, Variation, and Uncertainty Ignored

Traditional estimation quietly assumes:

stable requirements
clean dependencies
low variation
no major interruptions

Modern work is the opposite. Requirements evolve, incidents happen, stakeholders change direction. Estimation models that ignore this reality inevitably “fail”, and teams get blamed for what the system never allowed.

Politicised Numbers

When estimates decide whose work gets approved:

Engineering inflates to stay safe
Product shrinks to get work accepted
Finance pushes numbers down to fit budgets
Stakeholders push for aggressive dates

Accuracy is punished. Manipulation is rewarded.

Detached From Real Data

High‑maturity teams track throughput, cycle times, B1 load, and capacity patterns. Most teams rely on:

planning poker
whiteboard guesses
“it feels like a 5”

Without historical grounding, estimation is theatre.

Estimation Cannot Survive Organizational Drift

Even good estimates are destroyed by:

surprise B1 incidents
unbounded B3 demands
shifting priorities and scope
slow decisions and external dependencies

The problem isn’t the estimate. It’s the uncontrolled changes attacking it.

Estimation as a Source of Blame

When estimates slip:

engineers feel blamed
Intake Leads (Outcome Owners) feel exposed
leaders feel misled
stakeholders feel ignored

Defensive behaviour follows: sandbagging, hiding risk, and avoiding transparency. Blame kills the very honesty estimation needs.

Why This Matters for ODUI

Traditional estimation violates core ODUI principles:

no clear outcomes → misalignment
no capacity view → overload
no bucket control → chaos
no rhythm → instability
high pressure → unsafe environment

That’s why ODUI introduces estimation late in the maturity curve — after:

buckets stabilise
intake is consistent
B1/B3 patterns are visible
B2 is protected
rhythm is predictable

Only then can estimation be accurate, safe, and useful.

Estimation is not the problem. The environment is.

23.3 The ODUI Philosophy: Prioritisation First, Estimation Second

One of ODUI’s most important principles is simple:

You cannot estimate what you haven’t prioritised. You cannot prioritise what you haven’t understood.

Traditional sequence:

Idea appears
“Give me an estimate”
Idea is judged by size
Estimate becomes deadline
Reality collapses the plan

ODUI sequence:

Classify the work (B1/B2/B3/B4)
Define the outcome
Understand impact (KPI, urgency, alignment)
Review capacity
Prioritise based on trade‑offs
Only then estimate — if needed

Why This Order Matters

Estimation assumes:

stable priorities
visible capacity
defined outcomes
controlled B3

Without these, estimation becomes political. With ODUI, prioritisation creates the context estimation needs.

Not Everything Deserves Estimation

After ODUI classification:

B1 — no estimation, it’s reactive
B3 — bounded by capacity, not estimates
B4 — must not be estimated; it’s exploratory
B2 — benefits from estimation when it helps planning or trade‑offs

In most organisations 70–90% of what gets estimated never should be. ODUI cuts that waste.

Estimation Becomes Less Frequent and More Accurate

When ODUI is in place, estimations happen later, with:

clearer scope
better knowledge of risk
stable B1/B3 patterns
real throughput data

They naturally become more accurate — not because you changed the technique, but because you changed the environment.

23.4 Historical Throughput — The Only Trusted Estimation Source

Story points, T‑shirt sizes, Fibonacci scales — most methods are ritualised guessing. The only stable reference is historical throughput:

How much work a team actually completes under real conditions.

Throughput reflects:

B1 load and interruptions
maturity and automation
cross‑team dependencies
typical complexity and rework

It measures reality, not intention.

Why Throughput Beats Guessing

It’s grounded in what teams actually do, not what they hope to do.
It automatically captures local context and constraints.
It stabilises over time, smoothing random variation.
It exposes capacity limits no one can negotiate away.

How Throughput and ODUI Reinforce Each Other

ODUI makes throughput cleaner because work is:

bucketed and visible
split across predictable cycles
constrained by capacity limits

As buckets stabilise, throughput stabilises. As throughput stabilises, forecasting becomes trustworthy:

“We usually complete ~12 B2‑sized items per cycle.”
“This initiative is about 2 cycles of work.”

Estimation becomes a calm fact, not a pressure tool.

23.5 Who Owns Estimation (and Why It Cannot Be Intake Leads)

Many organisations implicitly make Intake Leads (Outcome Owners) responsible for estimates (often Product Managers / Product Owners). This always ends badly because Intake Leads sit at the intersection of:

stakeholder pressure
leadership expectations
customer needs
engineering constraints

They are structurally exposed to optimism, politics, and fear.

Estimation Must Be Owned by Delivery

Estimation should sit with Delivery‑oriented roles — typically the Flow Lead (Delivery Owner) (often a Delivery Manager / Project Manager / Scrum Master / Program Manager / Ops Lead).

Because they:

see real capacity and throughput
understand cross‑team impact
manage ODUI rhythm and bucket mix
are not judged by “selling” a specific feature

Intake Leads still play a crucial role:

define problems and outcomes
clarify scope and assumptions
connect work to customer and strategy

But Delivery translates that into what it will consume (effort) and when it is realistic (forecasting).

Intake Leads clarify the “what” and “why”. Engineers clarify complexity. Flow Leads forecast.

This triad keeps estimation grounded in reality and protects ODUI from political distortion.

23.6 How ODUI and Estimation Coexist Without Corrupting Each Other

ODUI and estimation solve different problems:

ODUI decides what deserves capacity.
Estimation decides how much capacity it will consume.

ODUI answers:

Is this urgent?
Is this important?
What outcome does it serve?
Which bucket does it belong to?

Only after that does estimation start.

The Clean Separation

Bucket decisions are based on urgency, importance, outcomes.
Capacity decisions are based on throughput and bucket mix.
Estimation helps place the chosen work inside the capacity boundary.

If estimation starts to influence bucket choices (“it’s small, so let’s call it B2”), ODUI collapses.

Prioritise with ODUI. Plan with throughput. Forecast with estimation.

When this rule is respected, ODUI and estimation reinforce each other instead of competing.

23.7 Commitment Sizing (MDW) — Deep Time Estimation Without Breaking ODUI

Sometimes leaders need more than “S / M / L”. They need a deep effort estimate in hours or days (MDW), so they can:

approve funding or staffing
approve cross‑team commitments
decide whether to park the work or start it

ODUI supports this — with strict rules, because this is the most misused part of estimation.

23.7.1 What Commitment Sizing Is (and Isn’t)

Commitment Sizing is:

a deep effort estimate (MDW) for a specific work package
used to support a go / park / split / decline decision
owned by Delivery (Flow Lead + team input)

Commitment Sizing is not:

a delivery date
a contract you can whip people with
a way to re‑argue prioritisation

23.7.2 When to Use Commitment Sizing

Commitment Sizing is not about “big” or “small”. Size is subjective.

Use it when the decision impact is high, for example:

it changes budget or headcount
it creates a public commitment (customer, legal, partner)
it is a one‑way door (hard to reverse)
it depends on other teams or vendors
it will consume a meaningful slice of B2 capacity for one or more cycles

If none of these are true, don’t do deep estimation. Use lightweight ranges.

23.7.3 The Non‑Negotiable Order

Commitment Sizing happens only after bucket allocation and prioritisation are finished.

That means:

Bucket is chosen (B1–B4)
Outcome is clear (especially for B2)
Capacity reality is visible (bucket mix)
The work is prioritised against alternatives
Only then do we do Commitment Sizing (MDW)

This protects ODUI from a common failure mode:

“We estimated it, so now we must do it.”

23.7.4 What the Delivery Team Must Produce

A Commitment Sizing output should be simple and decision‑ready:

Scope boundaries (in / out)
Effort range in MDW (Low / Likely / High)
Assumptions (what must stay true)
Dependencies (teams, vendors, approvals)
Risks and unknowns (what could blow up the estimate)
Capacity impact (what bucket time it will consume)

This keeps numbers honest and prevents “single‑number fantasy”.

23.7.5 Executive Decision Outcomes

After reviewing the Commitment Sizing output, leaders choose one:

Approve → Flow Lead can plan it into capacity.
Park → valuable, but not now. Keep it visible, add a review date.
Split → approve a smaller slice first (reduces risk and improves learning).
Decline → archive with a one‑line reason.

Important: “Park” is not “dead”. “Decline” is dead.

23.7.6 Anti‑Patterns (What to Stop Immediately)

Deep sizing before prioritisation (“estimate it so we can decide”) → guarantees politics.
Using MDW as a weapon → causes padding, fear, and dishonesty.
Treating a single number as truth → always wrong; use ranges.
Turning every task into a deep estimate → destroys flow.
Converting MDW into dates without capacity context → creates fake calendars.

23.8 Using Estimation for Forecasting, Budgeting, and Strategic Planning

Estimation becomes powerful when it supports strategic clarity, not micro‑control.

Forecasting Delivery Windows

Combined with throughput, estimation helps you answer:

roughly which cycle a work package may land in
when an outcome could realistically move
how long a multi‑cycle bet may take

You forecast ranges, not hard dates.

Budgeting From Real Capacity

With ODUI and historical data you can:

estimate how much B2 fits per quarter
model B1/B3 load realistically
link roadmap ambition to actual capacity

Budgets stop assuming fantasy velocity.

Portfolio Trade‑offs

For high‑impact work you can:

model total effort across teams
approximate cost and burn‑rate
compare bets by cost vs potential outcome

Finance gets predictability without turning estimates into whips.

ODUI tells you what matters. Estimation tells you what it costs. Finance decides if the bet is worth it.

23.9 Estimation for B2, B3, and B4 Work

Estimating B2 — Strategic Improvement Work

B2 is where estimation adds real value, because leaders must weigh:

how long a KPI‑moving work package may take
how much B2 capacity it consumes
how it compares to other B2 options

Rule: Estimate B2 after outcomes and KPIs are clear.

Use coarse ranges by default:

S = 1–2 weeks
M = 2–6 weeks
L = 6–12 weeks
XL = 12+ weeks

Use Commitment Sizing (MDW) only when the decision impact requires it (see 23.7).

Avoid precision theatre or breaking everything into dozens of micro‑tasks.

Estimating B3 — Stakeholder Requests

B3 is emotionally loaded. Estimation must not become a negotiation weapon.

Rule: Decide B3 acceptance using bucket logic and capacity caps first.

Estimate B3 only after it’s accepted into the cycle. Keep it light unless it triggers Commitment Sizing conditions.

Estimating B4 — Ideas and Innovation

Rule: B4 is not estimated.

Ideas are early and speculative. Estimating them:

kills promising ideas too soon
creates fake precision
turns exploration into half‑promises

Let B4 breathe. Use small spikes and prototypes instead of estimates. Convert to B2 only when an outcome and KPI are defined.

23.10 Preventing Estimation From Manipulating Bucket Decisions

Estimation is useful but dangerous. It must never override ODUI.

Guardrail 1 — Size Does Not Define Urgency

Phrases like:

“It’s only two hours.”
“It’s a tiny fix, just squeeze it in.”

…must be treated as red flags.

Bucket classification is based on urgency, importance, and outcome — not estimated duration.

Guardrail 2 — Leaders Cannot Use Small Estimates to Sabotage B2

Even “one‑day” tasks break flow. If leaders routinely pause B2 for “quick B3s”, strategy dies by a thousand cuts.

No estimate — small or large — can override the agreed bucket mix.

Guardrail 3 — Estimation Must Not Hide Work

Teams sometimes under‑estimate to avoid conflict or to “fit” B3. ODUI counters this by anchoring reality in throughput. If work consistently overruns its estimates, the pattern is visible.

Guardrail 4 — Estimation Cannot Replace Outcome Clarity

Having an estimate does not mean the work is ready. No work should start without a clear outcome and success criteria. Estimation cannot compensate for missing thinking.

Guardrail 5 — Capacity Is Based on Throughput, Not Estimates

Estimates are predictions. Throughput is what actually happened. ODUI plans cycles from throughput, then uses estimation to position work within that boundary.

Estimate after the bucket is chosen — never before.

This one sentence protects 90% of the system from corruption.

23.11 How High‑Maturity Companies Treat Estimation

High‑performing organisations do not obsess over precision. They optimise for flow, predictability, and impact.

Amazon uses deeper sizing mainly for “one‑way door” decisions, not every feature. Two‑way doors are decided quickly with minimal estimation.
Spotify relies on throughput and S/M/L sizing, not detailed points. Prediction matters less than maintaining healthy flow.
Apple lets vision define priorities first. Estimation is used to sequence what already matters, not to decide what deserves to exist.
Google uses estimation at portfolio level to understand capacity and risk, not to micro‑police teams.

Common pattern:

prioritisation before estimation
ranges over precision
throughput over opinion
impact over busyness

The best companies estimate — but they never let estimation run the organisation.

23.12 A Practical Estimation Framework That Complements ODUI

This is a lightweight framework you can drop into ODUI without breaking it.

Step 1 — Classify First

Choose the bucket (B1–B4).
For B2, define the outcome and KPI.
Confirm urgency and importance.

No estimation before this step.

Step 2 — Choose the Right Estimation Depth

B1 — no estimation. Fix or contain.
B4 — do not estimate. Prototype instead.
B2 / B3 — choose one:
Light sizing (S/M/L/XL) for most work.
Commitment Sizing (MDW) only when the decision impact requires it (23.7).

Step 3 — Anchor Forecasts in Throughput

Use historical throughput to decide:

how much work fits in the next cycle
what B2 load is realistic
how much B3 can be accepted

Estimation refines; throughput constrains.

Step 4 — Use Estimates for Planning, Not Prioritisation

Estimation helps with:

sequencing
aligning expectations
coordinating across teams

It must not be used to:

win prioritisation battles
justify urgency
override B2 protection

Step 5 — Review and Learn, Not Punish

Each cycle, review a sample of work:

Were ranges broadly correct?
Did B1/B3 disrupt more than assumed?
Do we need to adjust patterns or ranges?

The goal is to refine the system, not to find someone to blame.

23.13 Estimation Anti‑Patterns to Avoid

Most damage comes from misusing estimation. These are the patterns to actively eliminate:

Estimating before prioritising → leads to small, noisy work crowding out strategic B2.
Using size to justify urgency → “It’s small, so it must be urgent” breaks bucket logic.
Precision theatre → long debates over exact points, fake confidence.
Under‑estimating to get work approved → guarantees missed commitments and mistrust.
Micro‑splitting work for fake predictability → slows everyone down without improving accuracy.
Estimating B4 ideas → kills innovation and turns exploration into obligation.
Judging teams by estimate accuracy → leads to gaming; use throughput instead.
Treating estimates as contracts → forces people to manipulate numbers to survive.
Letting estimates override B2 protection → each “quick” B3 slowly suffocates strategy.
Believing better estimation will fix chaos → only ODUI (buckets, capacity, rhythm) can do that.

23.14 How Estimation Evolves as ODUI Matures

As ODUI takes root, estimation goes through predictable stages.

Chaotic estimation (weeks 1–4) Buckets feel new. Hidden work appears. B1/B3 overwhelm plans. Estimates feel random. This is normal.
Stabilised estimation (weeks 5–12) Intake works. B1/B3 patterns emerge. B2 is protected. Teams start using ranges without fear.
Throughput‑anchored estimation (months 4–6) Cycle data accumulates. Throughput patterns stabilise. Estimation becomes realistic and lightweight.
Mature estimation (months 6–18) Estimation is decentralised, outcome‑anchored, and used calmly by both teams and leaders for planning.
Strategic asset (18+ months) Estimation feeds portfolio decisions, risk analysis, and budgeting — without ever overriding ODUI.

At every stage, the rule holds: bucket decisions and outcomes come first.

23.15 Estimation as a Support System, Not a Decision System

Estimation will never disappear. But ODUI changes its role.

ODUI provides clarity (what matters)
ODUI provides boundaries (capacity and buckets)
ODUI provides rhythm (weekly, monthly, quarterly)

Estimation provides:

forecasting and budgeting input
coordination and sequencing
realistic expectations

The Backbone: Historical Throughput

The only estimation input you should truly trust is what your teams have actually delivered. Throughput removes politics, wishful thinking, and fake precision.

The Non‑Negotiable Rule

No estimation result may override bucket classification or capacity limits.

If an estimate contradicts ODUI, ODUI wins:

If it doesn’t fit capacity, it moves or waits.
If it conflicts with bucket rules, the bucket rules stand.

The Final Message

Estimation is essential — but not foundational.

ODUI gives you:

shared language
sane expectations
protected strategy
predictable cycles

Estimation then clicks into place as one of ODUI’s plugins:

It informs decisions. It does not dictate them.

When you hold that line, you get the best of both worlds:

a calm, outcome‑driven ODUI system
and an honest, lightweight estimation practice that finally works in the real world.

23.16 The ODUI Language

Here are the new ODUI terms introduced or used heavily in this chapter.

Term	Meaning
Estimation	A prediction used to support decisions. In ODUI it must not become a promise or a weapon.
Time estimation (MDW)	Effort in hours/days (man‑days of work). Not a delivery date.
Commitment Sizing (MDW)	Deep time estimation (effort range + assumptions) used for a go/park/split/decline decision. Happens only after bucketing + prioritisation.
Forecast (range)	A likely delivery window expressed as a range, not a single date.
Historical throughput	The most trusted estimation input: how much the team actually finishes under real conditions.
Capacity context	The bucket mix reality (B1–B4) that limits what can fit, regardless of estimate.
Precision theatre	Long debates and fake confidence in exact numbers that do not improve predictability.
S/M/L/XL sizing	Coarse estimation ranges (often by weeks) that reduce drama and keep planning lightweight.
Estimate vs commitment	An estimate is a prediction; a commitment is a decision with trade‑offs and ownership. Don’t confuse them.
Politicised estimation	When numbers are manipulated to win approval or avoid conflict rather than reflect reality.
Environment of estimation	The conditions around estimation (B1/B3 noise, unstable priorities) that determine whether estimates can be accurate.
Throughput‑anchored planning	Planning based on what teams actually deliver, then using estimates only to position work inside that boundary.
Triad (Outcome / Complexity / Forecast)	The ODUI estimation triangle: Intake Leads clarify outcome, engineers clarify complexity, Flow Leads forecast.
One‑way door / two‑way door	A big irreversible decision (one‑way) vs a reversible one (two‑way). One‑way doors deserve more careful sizing.

Core ODUI questions (Chapter 23)

Have we prioritised this with ODUI before estimating it?
Which bucket is this — B1, B2, B3, or B4?
What outcome and KPI does this support (if it’s B2)?
Do we have capacity for this within our bucket mix — or what must move?
Are we estimating effort (MDW) or pretending we know a delivery date?
What does our historical throughput tell us about what is realistic?
Are we treating an estimate as a commitment?
Is size being used to justify urgency (a red flag)?
Does this decision require Commitment Sizing — or is lightweight sizing enough?