Back to Details

estimation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Estimation

估算

When to Use This Skill

何时使用本技能

Use this skill when:
  • Estimation tasks - Working on estimation techniques including analogous, parametric, three-point, and expert judgment methods. provides effort, cost, duration, and complexity estimates for projects, features, and tasks
  • Planning or design - Need guidance on Estimation approaches
  • Best practices - Want to follow established patterns and standards
当你遇到以下场景时可使用本技能：
  • 估算任务：处理涉及类比法、参数法、三点法和专家判断法的估算工作，为项目、功能和任务输出工作量、成本、周期和复杂度估算结果
  • 规划或设计阶段：需要获取估算方法相关指导
  • 遵循最佳实践：希望遵循成熟的模式和标准开展工作

Overview

概述

Systematically estimate effort, cost, duration, and complexity using proven estimation techniques. Supports analogous, parametric, three-point (PERT), and expert judgment methods for projects, features, and tasks.
使用经过验证的估算技术，系统地估算工作量、成本、周期和复杂度。支持对项目、功能和任务使用类比法、参数法、三点法（PERT）和专家判断法。

What is Estimation?

什么是估算？

Estimation is the process of forecasting the resources, time, and cost required to complete work. Good estimation balances:
  • Accuracy: How close to actual results
  • Precision: Consistency of estimates
  • Speed: Time to produce estimates
  • Communication: Shared understanding of uncertainty
估算是预测完成工作所需资源、时间和成本的过程。优质的估算需要平衡以下维度：
  • 准确性：估算结果与实际值的接近程度
  • 精确性：多次估算结果的一致性
  • 速度：生成估算结果花费的时间
  • 沟通性：各方对估算不确定性的共识程度

Estimation vs Commitment

估算 vs 承诺

ConceptDefinitionUse
EstimateBest guess given current knowledgePlanning, forecasting
CommitmentPromise to deliver by date/costContracts, deadlines
TargetDesired outcome to aim forGoals, objectives
Key principle: Estimates are ranges with uncertainty, not single-point guarantees.
概念定义用途
估算基于当前信息得出的最优判断规划、预测
承诺按约定日期/成本交付的承诺合同、截止时间
目标期望达成的结果目的、指标
核心原则：估算是带不确定性的区间值，而非单点保证。

Estimation Techniques

估算技术

Analogous Estimation (Top-Down)

类比估算（自上而下）

Estimate based on similar past work:
StepAction
1Identify similar completed project/feature
2Retrieve actual effort/cost/duration
3Adjust for differences (complexity, team, technology)
4Apply adjustment factor
Formula:
text
New Estimate = Historical Actual × Adjustment Factor

Example:
Similar project took 200 hours
New project is ~20% more complex
Estimate = 200 × 1.20 = 240 hours
When to Use: Early phases, limited detail, experienced teams with historical data
Accuracy: +/- 25-50% (improves with good historical data)
基于类似的过往工作进行估算：
步骤操作
1找到相似的已完成项目/功能
2获取该项目的实际工作量/成本/周期
3根据差异（复杂度、团队、技术栈）调整
4应用调整系数计算结果
公式：
text
New Estimate = Historical Actual × Adjustment Factor

Example:
Similar project took 200 hours
New project is ~20% more complex
Estimate = 200 × 1.20 = 240 hours
适用场景： 项目早期阶段、细节信息有限、团队有丰富历史数据积累
准确率： +/- 25-50%（历史数据质量越高准确率越高）

Parametric Estimation

参数估算

Estimate using statistical relationships:
ElementDescription
Unit of WorkMeasurable element (screen, API, table)
Productivity RateEffort per unit from historical data
QuantityNumber of units to produce
Formula:
text
Estimate = Quantity × Productivity Rate

Example:
10 API endpoints × 16 hours/endpoint = 160 hours
Common Productivity Metrics:
Work TypeMetricTypical Range
UI screensHours/screen8-40 hours
API endpointsHours/endpoint4-24 hours
Database tablesHours/table4-16 hours
Test casesHours/test0.5-4 hours
Documentation pagesHours/page2-8 hours
When to Use: Repeatable work, good historical data, similar technology
Accuracy: +/- 15-25% (with calibrated rates)
使用统计关系进行估算：
元素描述
工作单元可量化的工作项（页面、API、数据库表）
生产率基于历史数据得出的单个工作单元所需工作量
数量需要完成的工作单元总数
公式：
text
Estimate = Quantity × Productivity Rate

Example:
10 API endpoints × 16 hours/endpoint = 160 hours
常用生产率指标：
工作类型指标典型范围
UI页面小时/页8-40小时
API接口小时/个4-24小时
数据库表小时/张4-16小时
测试用例小时/个0.5-4小时
文档页面小时/页2-8小时
适用场景： 可复用的重复工作、历史数据完善、技术栈相似度高
准确率： +/- 15-25%（生产率校准后可提升）

Three-Point Estimation (PERT)

三点估算（PERT）

Estimate using optimistic, most likely, and pessimistic values:
ValueSymbolDefinition
OptimisticOBest case, everything goes right
Most LikelyMMost probable outcome
PessimisticPWorst case, problems occur
PERT Formula (Weighted Average):
text
Expected = (O + 4M + P) / 6
Standard Deviation = (P - O) / 6

Example:
O = 5 days, M = 8 days, P = 17 days
Expected = (5 + 4×8 + 17) / 6 = 9 days
Std Dev = (17 - 5) / 6 = 2 days
Confidence Intervals:
ConfidenceCalculationExample (E=9, SD=2)
68%E ± 1 SD7-11 days
95%E ± 2 SD5-13 days
99.7%E ± 3 SD3-15 days
When to Use: Uncertain work, new technology, need to communicate risk
Accuracy: Provides explicit uncertainty range
使用乐观值、最可能值、悲观值三个维度进行估算：
值符号定义
乐观值O最优场景，所有环节都顺利
最可能值M概率最高的结果
悲观值P最差场景，出现各类问题
PERT公式（加权平均）：
text
Expected = (O + 4M + P) / 6
Standard Deviation = (P - O) / 6

Example:
O = 5 days, M = 8 days, P = 17 days
Expected = (5 + 4×8 + 17) / 6 = 9 days
Std Dev = (17 - 5) / 6 = 2 days
置信区间：
置信度计算方式示例（期望值=9，标准差=2）
68%期望值 ± 1倍标准差7-11天
95%期望值 ± 2倍标准差5-13天
99.7%期望值 ± 3倍标准差3-15天
适用场景： 不确定性高的工作、新技术栈、需要沟通风险
准确率： 可输出明确的不确定性区间

Expert Judgment

专家判断

Estimate using collective expert knowledge:
Wideband Delphi Process:
RoundActivity
1Experts estimate independently
2Collect and share anonymous estimates
3Discuss high/low outliers, share rationale
4Re-estimate independently
5Repeat until convergence (or average)
Planning Poker (Agile):
StepAction
1Present item to estimate
2Discuss briefly (2-5 minutes)
3Each team member selects card privately
4Reveal simultaneously
5Discuss outliers
6Re-vote until consensus
Common Scales:
Scale TypeValues
Fibonacci1, 2, 3, 5, 8, 13, 21, 34, 55, 89
Modified Fibonacci0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100
T-shirtXS, S, M, L, XL, XXL
Powers of 21, 2, 4, 8, 16, 32, 64
When to Use: Complex work, multiple perspectives needed, team alignment
基于专家集体知识进行估算：
宽带德尔菲流程：
轮次活动
1专家独立给出估算结果
2收集并匿名共享所有估算结果
3讨论最高/最低异常值，各自说明判断依据
4专家再次独立给出估算结果
5重复流程直到结果收敛（或取平均值）
计划扑克（敏捷场景）：
步骤操作
1展示待估算的工作项
2简短讨论（2-5分钟）
3所有团队成员私下选择对应点数的卡片
4同时亮出所有卡片
5讨论异常值的判断依据
6重新投票直到达成共识
常用估算尺度：
尺度类型取值
斐波那契数列1, 2, 3, 5, 8, 13, 21, 34, 55, 89
改良斐波那契数列0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100
T恤尺寸XS, S, M, L, XL, XXL
2的幂1, 2, 4, 8, 16, 32, 64
适用场景： 复杂工作、需要多视角评估、需要团队对齐认知

Function Point Analysis

功能点分析

Estimate based on functional size (for larger systems):
ComponentDescriptionWeight Range
External InputsData entering system3-6
External OutputsData leaving system4-7
External InquiriesRead-only queries3-6
Internal FilesLogical data stores7-15
External InterfacesShared data5-10
Process:
  1. Count each component type
  2. Classify complexity (low/medium/high)
  3. Apply weights
  4. Calculate unadjusted function points
  5. Apply technical complexity factor
When to Use: Large projects, formal contracts, industry benchmarking
基于功能规模进行估算（适用于大型系统）：
组件描述权重范围
外部输入进入系统的数据3-6
外部输出流出系统的数据4-7
外部查询只读查询3-6
内部文件逻辑数据存储7-15
外部接口共享数据5-10
流程：
  1. 统计每类组件的数量
  2. 按复杂度分类（低/中/高）
  3. 应用对应权重
  4. 计算未调整功能点
  5. 应用技术复杂度系数
适用场景： 大型项目、正式合同、行业基准对比

Relative Estimation

相对估算

Story Points

故事点

Relative complexity/effort measure:
PointsRelative SizeExample
1TrivialFix typo, config change
2SimpleSimple bug fix, minor feature
3ModerateStandard feature, moderate complexity
5ComplexMulti-component feature
8Very complexIntegration work, significant unknowns
13Epic-sizedConsider breaking down
21+Too largeMust decompose
Baseline: Pick a well-understood story as reference (e.g., "this is a 3")
Velocity: Story points completed per iteration (used for forecasting)
衡量相对复杂度/工作量的单位：
点数相对规模示例
1极简单修复错别字、修改配置
2简单简单bug修复、小型功能
3中等标准功能、中等复杂度
5复杂多组件联动的功能
8非常复杂集成工作、存在大量未知项
13史诗级规模建议拆分
21+规模过大必须拆分
基准： 选择一个共识度高的故事作为参考（比如“这个工作项是3点”）
速率： 每个迭代完成的故事点总数（用于后续预测）

T-Shirt Sizing

T恤尺寸估算

Quick relative sizing for roadmap planning:
SizeEffort RangeDuration Range
XS1-4 hours< 1 day
S0.5-2 days1-2 days
M2-5 days3-5 days
L1-2 weeks1-2 weeks
XL2-4 weeks2-4 weeks
XXL1-3 monthsToo big, decompose
用于路线图规划的快速相对估算方法：
尺寸工作量范围周期范围
XS1-4小时< 1天
S0.5-2天1-2天
M2-5天3-5天
L1-2周1-2周
XL2-4周2-4周
XXL1-3个月规模过大，需要拆分

Workflow

工作流程

Phase 1: Prepare

阶段1：准备

Step 1: Clarify Scope

步骤1：明确范围

markdown
undefined
markdown
undefined

Estimation Request

估算请求

Item: [What's being estimated] Requester: [Who needs the estimate] Purpose: [Planning/budgeting/commitment] Deadline: [When estimate is needed] Precision: [ROM/Budget/Definitive]
工作项： [待估算的内容] 请求方： [需要估算结果的人员/团队] 用途： [规划/预算/承诺] 截止时间： [需要交付估算结果的时间] 精度要求： [粗略量级/预算级/确定性级]

Scope Definition

范围定义

  • In Scope: [What's included]
  • Out of Scope: [What's excluded]
  • Assumptions: [Key assumptions]
  • Constraints: [Known constraints]
undefined
  • 包含范围： [估算包含的内容]
  • 排除范围： [估算不包含的内容]
  • 假设条件： [核心假设]
  • 约束条件： [已知约束]
undefined

Step 2: Select Estimation Technique

步骤2：选择估算技术

SituationRecommended Technique
Early project phaseAnalogous + T-shirt sizing
Detailed requirementsParametric + Three-point
Agile backlogStory points + Planning poker
New technology/domainExpert judgment + Three-point
Contract/budgetFunction points + Parametric
场景推荐技术
项目早期阶段类比法 + T恤尺寸估算
需求细节明确参数法 + 三点法
敏捷需求池故事点 + 计划扑克
新技术/新领域专家判断 + 三点法
合同/预算场景功能点 + 参数法

Phase 2: Estimate

阶段2：执行估算

Step 1: Decompose Work

步骤1：拆分工作

Break down into estimable units (half-day to 2-week chunks)
将工作拆分为可估算的单元（粒度控制在半天到2周之间）

Step 2: Apply Technique

步骤2：应用估算技术

Use selected technique(s) from above
使用上文选择的估算技术开展估算

Step 3: Add Contingency

步骤3：添加应急储备

markdown
undefined
markdown
undefined

Contingency Calculation

应急储备计算

Risk LevelContingencyWhen to Use
Low10-15%Well-understood, experienced team
Medium20-30%Some unknowns, new team members
High40-50%Significant unknowns, new technology
Very High75-100%Research, innovation, first-of-kind
undefined
风险等级应急储备比例适用场景
低10-15%工作内容清晰、团队经验丰富
中20-30%存在部分未知项、有新团队成员
高40-50%存在大量未知项、使用新技术
极高75-100%研究类、创新类、首次尝试的工作
undefined

Step 4: Validate

步骤4：验证结果

  • Sanity check against similar work
  • Review with team
  • Check for missing items
  • Verify assumptions
  • 和类似过往工作做合理性校验
  • 和团队一起评审
  • 检查是否有遗漏的工作项
  • 验证假设条件是否成立

Phase 3: Communicate

阶段3：沟通结果

Step 1: Express as Range

步骤1：以区间形式输出

markdown
undefined
markdown
undefined

Estimate Summary

估算汇总

Effort: 160-200 hours (confidence: 80%) Duration: 4-5 weeks (with 2 developers) Cost: $24,000-$30,000
Key Risks:
  • API integration complexity unknown
  • Dependency on third-party availability
undefined
工作量： 160-200小时（置信度：80%） 周期： 4-5周（2名开发人员投入） 成本： $24,000-$30,000
核心风险：
  • API集成复杂度未知
  • 依赖第三方服务的可用性
undefined

Step 2: Document Assumptions

步骤2：记录假设条件

markdown
undefined
markdown
undefined

Estimation Assumptions

估算假设条件

  1. Requirements are stable and complete
  2. Team has 80% availability (20% overhead)
  3. No major technology changes
  4. Dependencies delivered on time
  5. [Additional assumptions...]
If assumptions change, estimate should be revisited.
undefined
  1. 需求稳定且完整
  2. 团队可用度为80%（20%为 overhead）
  3. 无重大技术变更
  4. 依赖项按时交付
  5. [其他假设条件...]
如果假设条件发生变化，需要重新评估估算结果。
undefined

Output Formats

输出格式

Narrative Summary

文字总结

markdown
undefined
markdown
undefined

Estimation Summary

估算汇总

Item: [Feature/Project name] Date: [ISO date] Estimator: estimation-analyst Technique: [Technique used]
工作项： [功能/项目名称] 日期： [ISO格式日期] 估算人： estimation-analyst 使用技术： [使用的估算技术]

Estimate

估算结果

DimensionLowExpectedHighConfidence
Effort120h160h220h80%
Duration4w5w7w80%
Cost$18K$24K$33K80%
维度下限期望值上限置信度
工作量120h160h220h80%
周期4w5w7w80%
成本$18K$24K$33K80%

Basis of Estimate

估算依据

  • Historical Reference: [Similar past work]
  • Productivity Rate: [If parametric]
  • Expert Input: [Who contributed]
  • 历史参考： [类似过往工作]
  • 生产率： [参数法适用]
  • 专家输入： [参与估算的人员]

Assumptions

假设条件

  1. [Assumption 1]
  2. [Assumption 2]
  1. [假设条件1]
  2. [假设条件2]

Risks Affecting Estimate

影响估算的风险

RiskImpact on Estimate
[Risk 1]+20% if occurs
[Risk 2]+15% if occurs
风险对估算的影响
[风险1]发生的话增加20%工作量
[风险2]发生的话增加15%工作量

Recommendations

建议

  1. [Next steps for refining estimate]
  2. [When to re-estimate]
undefined
  1. [细化估算的下一步动作]
  2. [重新估算的触发条件]
undefined

Structured Data (YAML)

结构化数据（YAML）

yaml
estimation:
  version: "1.0"
  date: "2025-01-15"
  item: "User Dashboard Feature"
  estimator: "estimation-analyst"
  technique: "three_point"

  scope:
    description: "Interactive user dashboard with analytics"
    in_scope:
      - "Dashboard UI components"
      - "Data visualization"
      - "User preferences"
    out_of_scope:
      - "Backend analytics engine"
      - "Real-time updates"
    assumptions:
      - "API endpoints available"
      - "Design mockups complete"

  estimates:
    effort:
      optimistic: 120
      most_likely: 160
      pessimistic: 240
      expected: 166
      unit: "hours"
      std_deviation: 20
    duration:
      optimistic: 3
      most_likely: 4
      pessimistic: 6
      expected: 4.2
      unit: "weeks"
    cost:
      expected: 24000
      range_low: 18000
      range_high: 36000
      currency: "USD"

  confidence: 0.80
  contingency: 0.20

  breakdown:
    - component: "UI Components"
      effort: 60
      technique: "parametric"
      rate: "15h/component"
      quantity: 4
    - component: "Data Integration"
      effort: 40
      technique: "analogous"
      reference: "PROJ-123"
    - component: "Testing"
      effort: 40
      technique: "percentage"
      percentage: 0.25

  risks:
    - risk: "API complexity higher than expected"
      probability: 0.3
      impact_hours: 30
    - risk: "Design changes during development"
      probability: 0.2
      impact_hours: 20

  historical_comparison:
    similar_item: "Admin Dashboard"
    actual_effort: 180
    adjustment_factor: 0.9
yaml
estimation:
  version: "1.0"
  date: "2025-01-15"
  item: "User Dashboard Feature"
  estimator: "estimation-analyst"
  technique: "three_point"

  scope:
    description: "Interactive user dashboard with analytics"
    in_scope:
      - "Dashboard UI components"
      - "Data visualization"
      - "User preferences"
    out_of_scope:
      - "Backend analytics engine"
      - "Real-time updates"
    assumptions:
      - "API endpoints available"
      - "Design mockups complete"

  estimates:
    effort:
      optimistic: 120
      most_likely: 160
      pessimistic: 240
      expected: 166
      unit: "hours"
      std_deviation: 20
    duration:
      optimistic: 3
      most_likely: 4
      pessimistic: 6
      expected: 4.2
      unit: "weeks"
    cost:
      expected: 24000
      range_low: 18000
      range_high: 36000
      currency: "USD"

  confidence: 0.80
  contingency: 0.20

  breakdown:
    - component: "UI Components"
      effort: 60
      technique: "parametric"
      rate: "15h/component"
      quantity: 4
    - component: "Data Integration"
      effort: 40
      technique: "analogous"
      reference: "PROJ-123"
    - component: "Testing"
      effort: 40
      technique: "percentage"
      percentage: 0.25

  risks:
    - risk: "API complexity higher than expected"
      probability: 0.3
      impact_hours: 30
    - risk: "Design changes during development"
      probability: 0.2
      impact_hours: 20

  historical_comparison:
    similar_item: "Admin Dashboard"
    actual_effort: 180
    adjustment_factor: 0.9

Breakdown Table

拆分表格

markdown
undefined
markdown
undefined

Effort Breakdown

工作量拆分

ComponentTechniqueEstimateContingencyTotal
UI ComponentsParametric60h12h72h
Data IntegrationAnalogous40h10h50h
Testing% of Dev40h8h48h
DocumentationParametric16h4h20h
Subtotal156h34h190h
Management Overhead10%19h
Total209h
undefined
组件估算技术估算值应急储备总计
UI组件参数法60h12h72h
数据集成类比法40h10h50h
测试开发工作量占比40h8h48h
文档参数法16h4h20h
小计156h34h190h
管理 overhead10%19h
总计209h
undefined

Estimation Accuracy

估算准确率

Cone of Uncertainty

不确定性锥

Estimate accuracy improves as project progresses:
PhaseAccuracy Range
Initial concept0.25x - 4x
Approved project0.5x - 2x
Requirements complete0.67x - 1.5x
Detailed design0.8x - 1.25x
Code complete0.9x - 1.1x
Implication: Early estimates need wider ranges; refine as knowledge grows.
估算准确率会随着项目推进逐步提升：
阶段准确率范围
初始概念阶段0.25x - 4x
项目获批阶段0.5x - 2x
需求完成阶段0.67x - 1.5x
详细设计阶段0.8x - 1.25x
编码完成阶段0.9x - 1.1x
含义： 早期估算的区间需要更宽，随着信息完善逐步细化估算。

Estimation Levels

估算等级

LevelAccuracyWhen Used
ROM (Rough Order of Magnitude)-25% to +75%Initial budgeting
Budget-10% to +25%Project approval
Definitive-5% to +10%Execution baseline
等级准确率使用场景
ROM（粗略量级估算）-25% 到 +75%初步预算
预算级-10% 到 +25%项目审批
确定性级-5% 到 +10%执行基线

Common Pitfalls

常见误区

PitfallPrevention
Single-point estimatesAlways provide ranges
Optimism biasUse historical data, add contingency
AnchoringEstimate before seeing others' estimates
Planning fallacyInclude realistic overhead and risks
Scope creepDocument assumptions, re-estimate on changes
Precision theaterMatch precision to actual knowledge
误区预防方法
单点估算始终输出区间值
乐观偏差使用历史数据，添加应急储备
锚定效应在看到他人估算结果前先给出自己的判断
规划谬误计入合理的overhead和风险
范围蔓延记录假设条件，变更时重新估算
过度精确精度和当前掌握的信息匹配即可

Integration

上下游关联

Upstream

上游

  • Requirements - What to estimate
  • risk-analysis - Risks affecting estimates
  • stakeholder-analysis - Who needs estimates, precision required
  • 需求：待估算的内容
  • 风险分析：影响估算结果的风险
  • 干系人分析：估算结果的使用方、精度要求

Downstream

下游

  • Project planning - Resource allocation, scheduling
  • Budgeting - Cost forecasting
  • prioritization - Cost input for value/effort analysis
  • 项目规划：资源分配、排期
  • 预算：成本预测
  • 优先级排序：价值/工作量分析的成本输入

Related Skills

相关技能

  • risk-analysis
    - Risks affecting estimates
  • prioritization
    - Using estimates for prioritization
  • decision-analysis
    - Trade-off decisions
  • value-stream-mapping
    - Estimating process improvement effort
  • risk-analysis
    ：分析影响估算的风险
  • prioritization
    ：使用估算结果做优先级排序
  • decision-analysis
    ：权衡决策
  • value-stream-mapping
    ：估算流程改进的工作量

Version History

版本历史

  • v1.0.0 (2025-12-26): Initial release
  • v1.0.0 (2025-12-26)：首次发布