敏捷估算是什么
敏捷估算用相对规模而非绝对工时：团队选取一个基准故事，其他故事与之比较得出故事点，再结合历史速率预测能在一个迭代内完成多少工作。常用手段有计划扑克、斐波那契数列与 T 恤尺码。估算由执行团队共同完成，目的是让团队对规模形成共识，而不是给出精确日期承诺。
基本信息
| 参与者 | 实际执行的开发团队（掌估计的人），产品负责人负责澄清需求 |
|---|---|
| 常用数列 | 1、2、3、5、8、13、20（斐波那契）或 XS/S/M/L/XL |
| 时间盒 | 每条故事控制在 5-10 分钟内收敛，反复不收敛则先澄清需求 |
| 参考基准 | 选一条已完成的典型故事作为基准点，新故事与之比较 |
| 主要输出 | 故事点、团队速率、可预测的迭代容量 |
典型使用场景
- 迭代规划前补齐待办列表的规模估算，支撑本轮容量选择
- 新需求入场时快速判断规模量级，辅助优先级排序
- 版本预测：用历史速率推算若干迭代可交付的范围
- 估算分歧暴露：最高与最低估值差距大，往往说明需求理解不一致
- 团队校准：新成员加入后重新对齐基准故事与尺度
计划扑克流程（文字示意）
计划扑克流程（文字示意）
1) 产品负责人朗读故事与验收准则 # 先讲清价值与边界
2) 团队各自出牌，不做讨论 # 独立判断，避免被权威带动
3) 最高与最低者说明理由 # 差异即信息，通常暴露未知需求
4) 重新出牌直至收敛，记录估算值 # 不追求精确一致，达成可接受区间即可
5) 超过最大尺度的故事拆分后重新估算 # 过大的故事直接退回拆分
6) 用最近三个迭代的实际完成量更新团队速率 # 速率用于预测容量，不用于考核估算失准的应对
| 情形 | 可能原因 | 做法 |
|---|---|---|
| 明显偏小 | 故事过大、验收准则不明 | 拆分故事并补齐验收准则后重估 |
| 分歧过大 | 需求理解不一致或存在未知技术风险 | 安排时间盒探针，尽快用最小实验消除不确定性 |
| 连续偏小 | 估算基准漂移或容量未折算 | 复盘假设并更新基准故事与可用人日口径 |
| 估算被质疑 | 把故事点当工时用于考核 | 明确点数只用于队内预测，不换算工时与绩效 |
故事点不跨团队可比：不同团队的点数基准不同，跨团队比较速率会导致规模膨胀与虚报。跨团队场景应改看周期时间、吞吐量等客观指标。