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:

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公式：

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

输出格式

undefined

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

出现以下情况请拒绝：

工作属于探索性质（研究、技术调研）——使用时间盒而非估算
需求完全未定义——先明确范围
用户对大型项目要求精确到小时的精度——提供范围，而非虚假精度
估算将被用作承诺，且不承认不确定性",