estimate-calibrator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Estimate Calibrator

估算校准器

Replaces single-point guesses with structured three-point estimates: decomposes work into atomic units, estimates best/likely/worst case for each, identifies unknowns and assumptions, calculates aggregate ranges using PERT, and assigns confidence levels with explicit rationale.

用结构化的三点估算替代单点猜测：将工作分解为原子单元，为每个单元估算最佳/最可能/最差情况，识别未知因素和假设条件，使用PERT计算总范围，并结合明确的理由分配置信度。

Reference Files

参考文件

File	Contents	Load When
`references/estimation-methods.md`	PERT formula, three-point estimation, Monte Carlo basics	Always
`references/unknown-categories.md`	Technical, scope, external, and organizational uncertainty types	Unknown identification
`references/calibration-tips.md`	Cognitive biases in estimation, historical calibration, buffer strategies	Always
`references/sizing-heuristics.md`	Common task size patterns, complexity indicators, reference class data	Quick sizing needed

文件路径	内容	加载时机
`references/estimation-methods.md`	PERT公式、三点估算、蒙特卡洛基础	始终加载
`references/unknown-categories.md`	技术、范围、外部和组织类别的不确定性类型	识别未知因素时加载
`references/calibration-tips.md`	估算中的认知偏差、历史校准、缓冲策略	始终加载
`references/sizing-heuristics.md`	常见任务规模模式、复杂度指标、参考类别数据	需要快速估算时加载

Prerequisites

前置条件

Work item description (feature, task, project)
Decomposed tasks (or use task-decomposer skill first)
Context: team familiarity, tech stack, existing codebase

工作项描述（功能、任务、项目）
已分解的任务（或先使用task-decomposer工具）
上下文信息：团队熟悉度、技术栈、现有代码库

Workflow

工作流程

Phase 1: Decompose Work

阶段1：工作分解

If the work item is not already decomposed into atomic units:

Break into tasks — Each task should be estimable independently.
Right granularity — Tasks should be 1 hour to 3 days. Larger tasks have higher uncertainty; break them down further.
Identify dependencies — Tasks on the critical path determine the minimum duration.

如果工作项尚未分解为原子单元：

拆分为任务 — 每个任务应可独立估算。
合适的粒度 — 任务时长应在1小时到3天之间。较大的任务不确定性更高，需进一步拆分。
识别依赖关系 — 关键路径上的任务决定了最短工期。

Phase 2: Three-Point Estimate

阶段2：三点估算

For each task, estimate three scenarios:

Scenario	Definition	Mindset
Best case	Everything goes right. No surprises.	"If I've done this exact thing before"
Likely case	Normal friction. Some minor obstacles.	"Realistic expectation with typical setbacks"
Worst case	Significant problems. Not catastrophic.	"Murphy's law but not a disaster"

Key rule: Worst case is NOT "everything goes wrong." It's the realistic bad scenario (90th percentile), not the apocalyptic one (99th percentile).

针对每个任务，估算三种场景：

场景	定义	思考方式
最佳情况	一切顺利，无意外。	“如果我之前做过完全相同的事情”
最可能情况	存在正常阻力，有一些小障碍。	“考虑典型挫折后的现实预期”
最差情况	出现重大问题，但并非灾难性的。	“墨菲定律但不是毁灭性灾难”

核心规则： 最差情况并非“一切都出错”。它是符合现实的糟糕场景（第90百分位），而非极端灾难性场景（第99百分位）。

Phase 3: Identify Unknowns

阶段3：识别未知因素

Categorize unknowns that affect estimates:

Category	Example	Impact
Technical	"Never used this library before"	Likely case inflated, worst case much higher
Scope	"Requirements may change"	All estimates may shift
External	"Depends on API access from partner"	Blocking risk — could delay entirely
Integration	"Haven't tested with production data"	Hidden complexity at integration
Organizational	"Need design approval"	Calendar time, not effort time

对影响估算的未知因素进行分类：

类别	示例	影响
技术类	“从未使用过这个库”	最可能情况的估算值会偏高，最差情况的估算值会大幅升高
范围类	“需求可能会变更”	所有估算值都可能发生变动
外部类	“依赖合作伙伴的API访问权限”	阻塞风险 — 可能导致整体延迟
集成类	“尚未在生产数据中测试”	集成阶段可能存在隐藏复杂度
组织类	“需要设计审批”	占用日历时间，而非工作时长

Phase 4: Calculate Ranges

阶段4：计算范围

For individual tasks, use the PERT formula:

text

Expected = (Best + 4 × Likely + Worst) / 6
Std Dev = (Worst - Best) / 6

For aggregate (project) estimates:

Sum of expected values for total expected duration
Root sum of squares of std devs for aggregate uncertainty

针对单个任务，使用PERT公式：

text

Expected = (Best + 4 × Likely + Worst) / 6
Std Dev = (Worst - Best) / 6

针对整体（项目）估算：

总预期时长为各任务预期值之和
整体不确定性为各任务标准差的平方和的平方根

Phase 5: Assign Confidence

阶段5：分配置信度

Confidence	Meaning	When
High	Likely case within ±20%	Well-understood task, team has done it before
Medium	Likely case within ±50%	Some unknowns, moderate familiarity
Low	Likely case within ±100% or more	Significant unknowns, new technology

置信度	含义	适用场景
高	最可能情况的偏差在±20%以内	任务已充分理解，团队有相关经验
中	最可能情况的偏差在±50%以内	存在一些未知因素，团队有一定熟悉度
低	最可能情况的偏差在±100%或以上	存在大量未知因素，使用新技术

Output Format

输出格式

text

undefined

text

undefined

Estimate: {Work Item}

Summary

Scenario	Duration
Best case	{time}
Likely case	{time}
Worst case	{time}
PERT expected	{time}
Confidence	{High/Medium/Low}

Scenario	Duration
Best case	{time}
Likely case	{time}
Worst case	{time}
PERT expected	{time}
Confidence	{High/Medium/Low}

Task-Level Estimates

#	Task	Best	Likely	Worst	PERT	Unknowns
1	{task}	{time}	{time}	{time}	{time}	{key unknown or "None"}
2	{task}	{time}	{time}	{time}	{time}	{key unknown}
	Total	{sum}	{sum}	{sum}	{pert}

#	Task	Best	Likely	Worst	PERT	Unknowns
1	{task}	{time}	{time}	{time}	{time}	{key unknown or "None"}
2	{task}	{time}	{time}	{time}	{time}	{key unknown}
	Total	{sum}	{sum}	{sum}	{pert}

Key Unknowns

#	Unknown	Category	Impact on Estimate	Mitigation
1	{unknown}	{Technical/Scope/External}	+{time} if realized	{spike, prototype, early test}

#	Unknown	Category	Impact on Estimate	Mitigation
1	{unknown}	{Technical/Scope/External}	+{time} if realized	{spike, prototype, early test}

Assumptions

{Assumption 1 — what must be true for this estimate to hold}
{Assumption 2}

{Assumption 1 — what must be true for this estimate to hold}
{Assumption 2}

Risk Factors

{Risk}: If realized, adds {time}. Likelihood: {High/Medium/Low}.

{Risk}: If realized, adds {time}. Likelihood: {High/Medium/Low}.

Confidence Rationale

{High/Medium/Low} because:

{Specific reason — e.g., "Team has built 3 similar features"}
{Specific reason — e.g., "External API is a new integration"}

{High/Medium/Low} because:

{Specific reason — e.g., "Team has built 3 similar features"}
{Specific reason — e.g., "External API is a new integration"}

Recommendation

{Commit to PERT expected with {X}% buffer, or spike the top unknown first.}

undefined

{Commit to PERT expected with {X}% buffer, or spike the top unknown first.}

undefined

Calibration Rules

校准规则

Three points, not one. Single-point estimates are always wrong. Three points communicate uncertainty — the most important part of any estimate.
Worst case is the 90th percentile, not the 99th. "Asteroid hits the office" is not a useful worst case. "The API documentation is wrong and we need to reverse-engineer the protocol" is realistic worst case.
Unknowns inflate estimates more than known difficulty. A hard but well-understood task is more predictable than an easy but novel one.
Estimates are not commitments. Communicate ranges, not deadlines. If stakeholders need a single number, give the PERT expected plus a buffer for confidence level.
Spike unknowns early. If a single unknown dominates the estimate range, invest 1-2 days spiking it before estimating the rest.

用三点而非单点估算。单点估算永远不准确。三点估算能够传达不确定性——这是任何估算中最重要的部分。
最差情况是第90百分位，而非第99百分位。“小行星撞击办公室”不是有用的最差情况。“API文档错误，我们需要逆向工程协议”才是符合现实的最差情况。
未知因素比已知难度更会推高估算值。一项困难但已充分理解的任务比一项简单但新颖的任务更具可预测性。
估算不是承诺。传达范围而非截止日期。如果利益相关方需要单一数值，提供PERT预期值加上与置信度匹配的缓冲。
尽早排查未知因素。如果某个未知因素主导了估算范围，在估算其余部分之前投入1-2天时间进行排查。

Error Handling

错误处理

Problem	Resolution
Work item not decomposed	Decompose into 3-8 tasks first (or suggest task-decomposer skill).
No historical reference	Estimate relative to a known task: "This is about 2x the auth feature."
Stakeholder wants a single number	Provide PERT expected with buffer matching confidence level (High: +20%, Medium: +50%, Low: +100%).
Estimate seems too large	Check for scope creep in task list. Remove non-essential tasks. Identify what can be deferred.
Team has never done this type of work	Mark confidence as Low. Recommend a spike before committing to an estimate.

问题	解决方案
工作项未分解	先将其拆分为3-8个任务（或建议使用task-decomposer工具）。
无历史参考	相对于已知任务进行估算：“这项任务大约是认证功能的2倍。”
利益相关方想要单一数值	提供PERT预期值加上与置信度匹配的缓冲（高：+20%，中：+50%，低：+100%）。
估算值看起来过大	检查任务列表中是否存在范围蔓延。移除非必要任务。确定可推迟的内容。
团队从未做过此类工作	将置信度标记为低。建议在承诺估算前先进行排查。

When NOT to Estimate

不适宜估算的场景

Push back if:

The work is exploratory (research, spikes) — timebox instead of estimating
Requirements are completely undefined — define scope first
The user wants precision (hours) for a large project — provide ranges, not false precision
The estimate will be used as a commitment without acknowledging uncertainty

在以下情况时应拒绝估算：

工作具有探索性（研究、排查）—— 应设定时间盒而非估算
需求完全未定义—— 先明确范围
用户想要大型项目的精确估算（小时级）—— 提供范围，而非虚假的精确值
估算将被用作承诺，却不承认不确定性