待办梳理是什么
待办梳理是贯穿迭代的持续性活动：对即将进入迭代的条目补充细节、拆分粒度、重新估算，并提前暴露依赖与疑问，让它们在计划会上处于就绪状态。它不是一次性会议，也不是产品负责人独自补文档，而是需要团队参与并直接提问的协作过程。常见经验是把梳理占用的容量控制在团队容量的一定比例以内，避免细化工作挤占交付时间。
基本信息
| 目标 | 让待进入迭代的条目达到就绪状态，减少计划会上的临时判断 |
|---|---|
| 时机 | 每迭代固定安排，并在迭代中持续进行 |
| 容量参考 | 常见经验为团队容量的一成以内，具体按团队实际调整 |
| 产出 | 更清晰的验收标准、拆分后的条目、估算与依赖清单 |
| 参与角色 | 产品负责人牵头，开发与测试共同参与并直接提问 |
典型使用场景
- 计划会当天才发现条目过大无法排入迭代，需要提前拆分
- 验收标准模糊导致交付后返工，需要在梳理阶段写清判定条件
- 依赖关系在迭代中才暴露，需要提前识别并转交协调
- 需求理解偏差反复出现，需要开发与测试直接向产品方提问
- 待办顶部条目过多过细，需要控制细化深度避免方向变化后返工
梳理议程示例
梳理议程示例
1) 按优先级取待办顶部的若干条目（覆盖下一到两个迭代）
2) 逐条确认价值与目标：解决什么问题，成功如何判断
3) 补充验收标准与边界条件，明确不做什么
4) 拆分过大条目至团队可评估的粒度并重新估算
5) 识别依赖与疑问，指定跟进人和时限，会后更新待办就绪检查
| 检查项 | 判定 |
|---|---|
| 价值清楚 | 目标与用户价值能说明，能回答为什么做 |
| 规模可估 | 团队能给出区间估算，无需当场再拆分 |
| 可验收 | 验收标准初步明确，边界条件写清 |
| 依赖明确 | 外部依赖已识别并有人跟进 |
梳理不是产品负责人独自补文档：需要团队参与并直接提问。开发与测试在梳理阶段提出的疑问，比在开发中发现时修改成本低得多。