一、 核心原则：相对估算，而非绝对时间
拒绝“人天/人日”：因为每个人能力、状态、对需求的理解都不同，“这个需求需要3天”的评估非常主观且易失真。
采用“故事点”：故事点是一个相对复杂度、工作量和技术风险的综合衡量单位。它关注的是“需求A大概是需求B的几倍复杂？”，而不是“需要多少小时”。
二、 如何定义故事点？—— 建立团队统一的“基准尺”
关键： 绝不建议将“最基础的单表增删改查”机械地定义为1点。因为“基础”的定义因人而异，且无法应对复杂场景。
正确方法是：团队协作，共同定义一把“基准尺”。
步骤 1：召开“故事点估算启动会”
参会人： 全体开发、测试、产品负责人（可选）。
目标： 共同选出1-3个团队公认的、具有代表性的“基准用户故事”，并为其赋予故事点。
步骤 2：选择“基准故事”
选择那些已完成的、大家印象深刻的简单、中等、复杂的故事各一个。例如：
基准故事-S（简单）：
“作为一个用户，我可以在个人设置页面修改我的昵称和头像。”讨论： 后端只有一个API，前端一个页面，无需复杂校验，不涉及核心业务逻辑。团队一致认为这是“最简单的那类需求”。
共识： 我们将此类故事的复杂度定义为 1 个故事点。
基准故事-M（中等）：
“作为一个采购员，我可以创建一个采购申请单，包含商品、数量、期望到货日期，并能保存为草稿或提交审批。”讨论： 涉及多个字段、前后端联调、简单的状态机（草稿/已提交）、需要与审批流模块有轻度耦合。
共识： 这个故事明显比“修改昵称”复杂，但也不是最复杂的。我们感觉它的复杂度大概是“修改昵称”的 3倍。所以，我们将其定义为 3 个故事点。
基准故事-L（复杂）：
“作为一个财务人员，我可以生成月度财务报表，该报表需要从销售、采购、库存模块聚合数据，并支持按条件筛选和导出为Excel。”讨论： 涉及多模块数据集成、复杂查询、大数据量处理、外部文件操作，潜在的性能风险。
共识： 这个故事非常复杂，大概是“创建采购单”的2-3倍，甚至是“修改昵称”的8倍。我们将其定义为 8 个故事点。
步骤 3：使用“计划扑克”进行估算
产品经理讲解一个新需求。
每位开发者独立思考，将这个新需求与“基准故事S/M/L”进行比较，然后出牌（通常使用斐波那契数列扑克：1, 2, 3, 5, 8, 13, 20, 40, ?）。
大家同时亮牌。
如果估算差异大（如有人出3，有人出8），则让估算最高和最低的成员分别陈述理由。
基于讨论，重新估算，直到达成共识。
为什么用斐波那契数列？ 因为它体现了“不确定性随复杂度增加而增加”的理念。需求越复杂，我们越难精确预估，所以点数间隔应该越大。
三、 故事点估算考量维度（检查清单）
在估算时，团队应共同考虑以下因素，而不仅仅是代码行数：
四、 团队速率（Velocity）的计算与使用
1. 计算速率：
速率 = 过去2-3个迭代内，所有成功完成的、符合DoD（Definition of Done） 的用户故事点数的平均值。
示例： 迭代1完成 20点，迭代2完成 23点，迭代3完成 18点。则平均速率 = (20+23+18)/3 ≈ 20点。
2. 规划迭代容量（核心规则）：
迭代计划容量 = 平均速率 × 缓冲系数（建议0.7-0.8）
示例： 团队速率是20点，则本次迭代的计划工作量应为 20 * 0.8 = 16点。
为什么是80%？ 这20%的缓冲时间用于：修复本轮迭代产生的Bug、处理生产环境紧急问题、参加公司会议、技术债务偿还、需求微调等。绝对不能用100%的速率去规划，那注定会延期！
五、 流程总结与落地建议
给小范围讨论的建议：
先试点： 选择一个5-9人的团队进行1-2个迭代的试点。
复盘校准： 每个迭代结束后，复盘会上要讨论：“上个迭代的估算哪些准了？哪些偏了？为什么？” 不断修正团队对“故事点”的共同理解。
目标一致： 强调故事点的目的不是考核个人效率，而是帮助团队对自身能力建立准确的认知，从而做出可靠的承诺，提升交付 predictability（可预测性）。
通过这套方法，团队能逐渐形成自己独有的、稳定的“度量衡”，从而使迭代规划从“拍脑袋”变为“基于数据的科学决策”。