Estimation Workbench Guide

Purpose

The Estimation Workbench helps teams turn uncertain implementation work into a more structured forecast. It is designed for both solo and group estimation, and it separates uncertain work from already known work so the final estimate is easier to explain and defend.

Use it when you want to:

• capture a structured estimate instead of a single gut-feel number
• compare multiple estimators without immediately anchoring on one answer
• distinguish between uncertain implementation work and named known tasks
• convert effort into a delivery projection using team capacity assumptions
• generate a stakeholder-ready summary with confidence ranges

---

Quick Start

1. Choose how many estimators are contributing

• Set Estimators to 1 for solo estimation.
• Set Estimators to 2+ for blind group estimation.

What changes:

• In solo mode, estimates go straight into results.
• In group mode, estimates are collected first and revealed together.

2. Pick units

Choose the unit that best matches how your team thinks about work:

• Days
• Hours
• Weeks
• Story Points

3. Pick an estimation method

Use the method description in the workbench as the first guide. As a rule:

• PERT is the default for bounded implementation work.
• Three-Point is useful when optimistic and pessimistic bounds deserve equal weight.
• B/C/K/R is useful for exploratory or intuition-driven work.
• Analogous is best when you have a real historical comparison.
• Story Points is best when the team already plans in points and velocity.

4. Enter the estimate

Depending on the method, enter the required fields. For three-point estimates, the intended order is:

• Best Case <= Most Likely <= Worst Case

The workbench will show live warnings if these inputs are structurally inconsistent.

5. Add Known Tasks if applicable

Use Known Tasks for named work that is already understood and should not be hidden inside the uncertain estimate.

Examples:

• QA and regression
• release and rollout steps
• analytics or instrumentation
• documentation
• approvals
• migrations

6. Review Results

Once an estimate is revealed or submitted, the workbench can show:

• forecast ranges
• percentile-based confidence values
• capacity-based schedule projections
• stakeholder-facing summary output

---

Core Concepts

Unknown Work

This is the uncertain part of the estimate. It comes from the selected estimation method.

Examples:

• implementation complexity
• integration uncertainty
• edge cases still being discovered
• technical risk

Known Tasks

Known Tasks are not a second estimate of the same work. They are a separate bucket for already identified work items.

The main benefit is clarity:

• uncertain implementation work stays in the estimate model
• explicit named work stays visible as a task list

Do not count the same work in both places.

Team Overhead Multiplier

This scales the uncertain estimated work before known tasks are added.

Use it for delivery overhead such as:

• coordination
• code review
• meetings
• handoffs
• interruptions

Example:

• uncertain estimate: 10 days
• multiplier: 1.2
• adjusted uncertain work: 12 days

Known Work Buffer

This adds contingency only to Known Tasks.

Use it when known scoped work often grows because of:

• rework
• dependencies
• late detail
• process overhead

Example:

• known tasks subtotal: 4 days
• buffer: 25%
• buffered known work: 5 days

---

How Known Tasks Work

Each known task has a required Likely value.

In Advanced mode, a task can also include:

• Min
• Max
• category
• notes
• actual time later

The workbench:

1. sums known task effort
2. applies Known Work Buffer (%)
3. adds that buffered total to the uncertain estimate

If actuals are recorded for completed known tasks, the workbench can suggest a smarter known-work buffer based on historical variance.

---

Estimation Methods

PERT

Inputs:

• Best Case
• Most Likely
• Worst Case

Use PERT when the work is real but uncertain, and you can reasonably describe optimistic and pessimistic bounds.

Three-Point

Inputs:

• Best Case
• Most Likely
• Worst Case

Use this when you want the three points to carry equal weight rather than letting the middle value dominate.

B/C/K/R

Inputs:

• Base Guess
• Certainty
• Known-Unknowns
• Risk

Use this when a clean optimistic-to-pessimistic range is hard to define but informed judgment is still possible.

Analogous

Inputs:

• Reference Duration
• Similarity Factor
• Analogy Confidence

Use this when you have a real historical comparison.

Example:

• iOS implementation took 7 weeks
• Android should likely be faster because requirements are clearer and API challenges are now better known
• use 7 weeks as the reference, set Similarity Factor below 1.0, and tune confidence based on how comparable the work really is

Story Points

Inputs:

• Story Points
• Uncertainty

Use this when your delivery team plans in points and already trusts sprint velocity as the conversion into timeline.

---

Solo vs Group Workflow

Solo Workflow

Use solo mode when one person is estimating.

Recommended flow:

1. Set Estimators to 1
2. Pick units
3. Pick a method
4. Enter the estimate
5. Add Known Tasks if needed
6. Review results and schedule

Group Workflow

Use group mode when several people are estimating the same work.

Recommended flow:

1. Set Estimators to the expected number of contributors
2. Keep the session in collect mode
3. Have each estimator enter a blind estimate
4. Reveal together
5. Compare the spread
6. Discuss disagreements and rerun if needed

Why this matters:

• blind collection reduces anchoring
• spread helps surface uncertainty, assumptions, and missing information

---

Reading the Results

The workbench can show both direct estimate summaries and confidence-based forecasts.

Important values:

• Known Work: named scoped tasks plus known-work buffer
• P50: the median forecast
• P80: the recommended commitment point
• P95: a high-confidence upper bound

Interpretation:

• P50 is a midpoint, not a promise
• P80 is usually the best planning commitment for stakeholders
• P95 is useful for high-confidence ceilings and hard constraints

---

Delivery Team Capacity & Schedule

This section converts effort into a timeline.

It is about the team delivering the work, not the people providing estimates.

That means:

• Estimators = 1 can still be valid
• Delivery Team Size = 6 can still be valid

Inputs in this section are capacity assumptions, such as:

• delivery team size
• availability
• focus hours per day
• sprint length
• start date
• schedule basis

Use this section after you have at least one revealed estimate and need to answer:

• how long would this likely take with our actual team?
• how many sprints does this imply?
• what date range should we plan around?

---

Stakeholder Section

What stakeholders should know

The workbench does not produce a magic answer. It produces a structured forecast based on explicit assumptions.

That is a strength, not a weakness.

The forecast is stronger than a single number because it makes the following visible:

• uncertainty in the implementation estimate
• explicit named known work
• delivery overhead assumptions
• capacity assumptions
• confidence levels

How results are calculated

At a high level, the total forecast is built in layers:

1. the selected estimation method produces an uncertain work range
2. Team Overhead Multiplier adjusts that uncertain work
3. Known Tasks are summed separately
4. Known Work Buffer is applied to the known tasks
5. the workbench combines these into total forecast outputs
6. Monte Carlo simulation is used to generate percentile-based ranges such as P50, P80, and P95

Why stakeholders can trust the output more than a single-number estimate

Because the model is explicit about what usually gets hidden.

Instead of pretending the estimate is exact, it shows:

• what is known
• what is uncertain
• what assumptions are driving the forecast
• how aggressive or conservative the commitment is

Recommended stakeholder interpretation

• Treat P80 as the default planning commitment.
• Treat P50 as the median scenario, not a commitment.
• Treat P95 as a high-confidence ceiling.
• Revisit the forecast when scope, assumptions, or team capacity materially change.

What can still change the result

Stakeholders should expect the forecast to move if:

• scope changes
• requirements become more precise
• delivery team size or availability changes
• major risks are discovered or removed
• Known Tasks are added or clarified

This is normal forecasting behavior, not a sign that the tool failed.

---

Recommended Team Habits

• Use PERT or Analogous as the default starting point unless there is a strong reason to use another method.
• Keep Known Tasks explicit rather than folding them silently into the estimate.
• Use group mode when alignment matters and anchoring is a risk.
• Prefer P80 for planning commitments.
• Re-estimate after large requirement or architecture changes.
• Record actuals for Known Tasks when possible so future buffer suggestions improve.

---

Common Mistakes

• counting the same work in both the estimate and Known Tasks
• treating P50 as a commitment
• forgetting to update delivery capacity assumptions
• assuming number of estimators equals number of implementers
• using a historical reference without adjusting for platform, knowledge, or scope differences

---

One-Sentence Summary

Use the workbench to separate uncertain work from named known work, turn that into a confidence-based forecast, and then convert that forecast into a delivery timeline that is easier to explain to both engineers and stakeholders.