规划扑克要在一支研发团队里真正跑起来，关键不在牌面，而在会前把估算口径定清楚：点数代表相对规模，基准故事可供参照，待估条目粒度一致。本文按“定口径—走流程—分角色—写回工作项—示例—检查”的顺序，给出一套可重复执行的落地方法，适用于需求或故事级的投入预估环节。
要点总览（TL;DR）
- 落地前先定三件事：点数表示相对规模而非小时数、选定1–3个基准故事、约定估算对象粒度，写成一页口径说明。
- 单场会议按讲解、发牌、亮牌、极端值发言、复投、收敛推进，主持人保持中立，记录人留存点数、分歧理由与假设。
- 产品讲清需求边界，开发说明实现复杂度与依赖，测试补充验证范围与质量风险，小团队可兼角但职责要分清。
- 共识点数写回工作项估算字段，分歧与假设记入备注，迭代结束后做定性对照，用于校准基准故事和口径。
- 用会前、会中、会后检查清单验收落地效果，重点纠正点数当工时、主持人带倾向、基准故事漂移三类偏差。
先定估算口径：点数代表什么、基准故事怎么选
规划扑克最常见的失败，是会议开得很热闹，散会后每个人对“5点”的理解都不一样。避免这个问题，需要在第一次发牌之前完成三件事：明确点数的含义、选定基准故事、界定估算对象的粒度。这三项构成团队的估算口径，建议写成一页说明，放在团队都能看到的位置。
点数表示相对规模，不表示小时数
规划扑克使用的点数（常见为斐波那契序列：1、2、3、5、8、13……）表达的是条目之间的相对大小，综合了工作量、复杂度、不确定性和所需协作等因素。它回答的是“这个条目比基准故事大多少”，而不是“这个条目要做多少小时”。把点数直接换算成工时，会让估算变成承诺，团队在后续估算中倾向于保守或虚高，方法本身也就失去了意义。
口径说明中应写清：点数用于比较条目之间的相对规模，用于排期时参考排序与容量匹配；具体交付日期由排期环节结合团队可用时间另行确定。这条边界写清楚，能减少后续把点数当工时用的误解。
基准故事的选择标准与示例
基准故事是团队共同认可的参照物，通常选1到3个，覆盖“小、中、大”三档，让待估条目有可比对象。选择标准可以归纳为几条：已经完成、团队多数成员参与过、规模感受一致、实现路径清晰。基准故事不宜选争议大的条目，也不宜频繁更换。
示例（演示情景）：某团队选定三个基准故事——A为“列表页增加一个筛选条件”，定为2点；B为“新增一个带表单校验的配置页面”，定为5点；C为“改造订单状态流转并兼容历史数据”，定为13点。之后估算新条目时，团队先问“它比A大还是比B大”，再进入发牌。基准故事应连同点数一起记录在口径说明中，新成员加入时先读这份说明。
估算对象的粒度界定
同一场会议里混着需求和任务一起估，点数就失去可比性。落地前需约定估算对象：通常以用户故事或需求为估算单位，粒度控制在“一个迭代内可完成、可独立验证”的范围。过大的条目先拆分再估，过小的技术任务不进入规划扑克，由开发在任务层面自行安排。粒度约定同样写入口径说明，并在每次会前检查待估列表是否符合。
完成标志：团队产出一份点数口径说明，包含点数含义、1到3个基准故事及其点数、估算对象粒度约定，并在首次会议前由全体参与者确认。
一场规划扑克的完整操作步骤
单场会议可以压缩成一张流程卡：会前备好待估条目、基准故事和牌组，会中按讲解、发牌、亮牌、极端值发言、复投、收敛的顺序推进，会后由记录人整理结果。以下按时间顺序展开每个动作的输入与输出。
会前准备
- 待估条目：由产品负责人提前整理成列表，每条包含背景、目标、验收要点，粒度符合约定；条目数量控制在一场会议能充分讨论的范围内，估不完的顺延到下一场。
- 基准故事：把选定的基准故事及其点数带到会上，作为讨论参照。
- 牌组：准备一套点数牌，线上会议可用对应的估算工具或共享卡片。
- 参与人：确认产品、开发、测试均有人到场，主持人、记录人就位。
输出：一份可开会的待估列表和会议材料。
会中流程
- 讲解：业务方逐条说明条目背景、边界和验收要点，讲解以说清“要解决什么问题”为准，不展开实现方案。
- 发牌：参与者各自选牌，同时亮牌，避免相互影响。
- 亮牌后处理分歧：点数一致或接近时直接进入下一条；出现极端值时，请持最小点和最大点的成员分别说明理由，聚焦“哪里不确定、哪里复杂度高”，其他人补充信息。
- 复投：信息补充后重新发牌亮牌，通常一到两轮即可收敛。
- 收敛：达成一致即记录点数；仍不一致时，由主持人确认是否信息不足，必要时把条目拆小或标记为待补充后再估，不强行取平均值。
输出：每条待估条目的共识点数，以及分歧点和假设的记录。
收敛规则与记录方式
收敛规则建议提前约定：允许的牌面差距范围、最多复投轮次、无法收敛时的处理方式（拆分、补充信息或暂缓）。记录人同步记下点数、持不同意见者的主要理由、会上形成的假设（例如“假设复用现有组件”）。这些记录是后续复盘对照的依据，比单纯的点数更有价值。
角色分工与各自交付物
规划扑克是一场多方参与的会议，角色清楚，讨论才不会跑偏。核心角色包括主持人、业务方、开发、测试和记录人，小团队可以一人兼多角，但职责要分清。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 主持人 | 控制流程与节奏，维持中立，引导极端值发言，判断是否收敛 | 会议按流程完成，收敛结论明确 |
| 业务方（产品） | 讲解条目背景、边界与验收要点，回答范围问题 | 清晰的待估条目说明 |
| 开发 | 从实现角度说明复杂度、技术不确定性和依赖 | 实现侧的风险与假设 |
| 测试 | 从验证角度说明测试范围、场景复杂度和质量风险 | 验证侧的复杂度输入 |
| 记录人 | 记录点数、分歧理由与假设，整理会后结果 | 估算记录 |
主持人的中立性尤其重要：主持人可以提问、可以提醒口径，但不宜率先表态或暗示自己倾向的点数，否则后续亮牌容易被带偏。业务方讲解时聚焦需求边界，避免在会上直接给出实现方案，把技术判断留给开发与测试。记录人的产出应在会后当天完成整理，避免记忆衰减导致记录失真。
估算结果如何写回工作项并留痕
估算如果只停留在会议记录里，排期和复盘时就用不上。落地的一步是把共识点数写回对应工作项，并保留分歧与假设。具体字段名称因团队所用工具而异，但内容结构可以统一约定。
点数写入工作项字段
为工作项设置一个估算字段，写入共识点数；同时保留估算日期和参与估算的版本信息，便于后续追溯。点数一经写入，后续变更应留下记录，而不是直接覆盖。
分歧与假设的记录位置
建议在工作项的备注或评论中记录：会上出现的主要分歧点、形成的关键假设、以及未收敛时的处理方式（拆分或待补充）。这些内容在需求变更或复盘时能解释“当时为什么估这个点”。
估算与实际投入的对照方式
点数不直接对应工时，但可以在迭代结束后做定性对照：实际投入明显偏离估算的条目，回看当时的假设是否成立、是否遗漏了复杂度。对照的目的是校准基准故事和口径，而不是考核个人。若团队使用ONES承载研发工作项，可以把估算点数放在工作项的自定义字段中，分歧与假设写在描述或评论里，使估算记录与需求、任务处于同一处，排期和回顾时直接查阅，减少在多个文档之间来回核对。
一个迭代内的落地示例
以下为演示情景，用于说明流程如何串起来，数据为示例设定。
示例背景与待估条目
某研发团队进入新迭代规划，待估列表有四个条目：D“消息中心增加已读标记”、E“导出报表支持按时间范围筛选”、F“接入新的支付渠道”、G“优化首页加载速度”。团队沿用前述口径：基准故事A为2点、B为5点、C为13点。
一次出现极端分歧的处理过程
估到F“接入新的支付渠道”时，亮牌出现2点和13点。主持人请持2点的成员先说明：其判断依据是“有现成文档，按流程对接即可”。持13点的成员说明：该渠道的回调机制与现有系统不一致，需要改造对账逻辑，且测试环境尚未就绪。测试补充该渠道的异常场景验证工作量较大。信息补充后复投，牌面收敛到8点，团队同时记录假设：“对账逻辑改造范围以现有订单模型为准，若需调整模型另行评估。”
最终点数与记录结果
四个条目最终点数为：D为2点、E为3点、F为8点、G为5点。记录人将点数写入各工作项，F的分歧理由与假设记入备注。迭代结束后回顾时，团队发现F实际投入高于预期，回看记录确认是对账逻辑改造范围扩大所致，据此在下一次估算类似条目时把“对账改造”列为需要单独确认的复杂度因素。
落地检查清单与常见偏差
判断规划扑克是否落地到位，可以按会前、会中、会后逐项核对；同时留意几类高频偏差，在迭代回顾中及时修正。
检查清单
| 阶段 | 检查项 | 完成标志 |
|---|---|---|
| 会前 | 待估条目粒度符合约定，说明包含背景与验收要点 | 待估列表可直接开会 |
| 会前 | 基准故事及点数已准备，口径说明可查 | 会议材料齐全 |
| 会中 | 讲解聚焦需求边界，未提前给实现方案 | 讨论围绕范围展开 |
| 会中 | 同时亮牌，极端值双方均发言，复投有记录 | 分歧处理过程可追溯 |
| 会后 | 点数写入工作项，分歧与假设已记录 | 工作项信息完整 |
| 会后 | 迭代结束做估算与实际投入的对照 | 形成口径调整建议 |
常见偏差与应对
| 偏差 | 表现 | 应对 |
|---|---|---|
| 点数被当作工时承诺 | 排期时直接按点数折算天数，团队估算趋于保守 | 重申点数表示相对规模，排期结合可用容量另行确定 |
| 主持人带倾向 | 主持人先亮牌或暗示答案，后续牌面趋同 | 主持人只提问不表态，必要时轮换主持 |
| 基准故事漂移 | 基准故事被频繁替换，前后点数不可比 | 基准故事保持稳定，确需更换时同步更新口径说明并记录 |
| 条目粒度过大 | 单条估算耗时过长，分歧难以收敛 | 会前拆分，超过约定粒度的条目不进入估算 |
口径的调整放在迭代回顾中进行：对照估算与实际投入的偏差，判断是基准故事需要补充、粒度约定需要收紧，还是某类复杂度因素应纳入常规讨论。每次调整只改一到两项，并在下一次估算中验证效果，避免口径频繁变动导致团队无所适从。
常见问题
团队第一次开规划扑克，基准故事还没定，能不能先估起来？
可以先开，但建议把第一场定位为“定基准”的会议，而不是正式估算。做法是从已完成的历史条目中挑出团队多数人参与过、规模感受一致的2到3个，现场讨论后定为小、中、大三档基准，并记录点数。第二场再进入正式估算。跳过基准直接估，容易出现每个人心里各有一套参照，牌面分歧大且难以解释。
亮牌后分歧一直收敛不了，是继续复投还是直接取平均值？
不建议取平均值，平均值会掩盖真实分歧。先判断分歧来源：如果是信息不足，请持极端值的成员说明具体不确定点，补充信息后复投；如果条目本身过大，拆小后再估；如果涉及方案选择尚未确定，标记为待补充，暂缓估算。会前约定最多复投轮次（通常一到两轮），超过轮次仍不收敛就按上述方式处理，并记录未收敛原因。
远程或分布式团队怎么组织发牌和亮牌？
核心是保证“同时亮牌、互不影响”。线上会议可用估算工具或共享卡片，参与者先各自选好，由主持人统一触发亮牌；没有专用工具时，也可以让成员把点数私发给记录人，由记录人汇总后同时公布。讲解环节提前把条目说明发给参会人预读，能压缩会议时间。远程场景下主持人更要主动点名请极端值双方发言，避免沉默成员的意见被忽略。
点数写进工作项之后，排期时能不能直接按点数折算人天？
不建议直接折算。点数表达相对规模，排期需要结合团队可用容量、依赖关系和具体交付日期另行确定。可行的做法是把点数用于排序和容量匹配的参考：先按点数排出条目相对大小，再结合迭代内可用人力判断能承接多少。若团队长期把点数当工时用，估算会逐渐趋于保守或虚高，方法本身也失去校准价值。
估算口径定好之后，多久需要回顾和调整一次？
建议放在迭代回顾中顺带检查，不必单独设会。对照估算与实际投入明显偏离的条目，判断原因：是基准故事不够用、粒度约定太松，还是某类复杂度因素在估算时被系统性忽略。每次调整只改一到两项，并在下一次估算中验证效果。基准故事确需更换时，同步更新口径说明并记录更换时间，避免前后点数不可比。
