技能介绍

它解决什么问题

产品待办常常坏在三处：需求写成“优化体验”这类无法验收的描述；Epic 直接拆成 13+ 点的大故事，导致冲刺塞进太多承诺；优先级靠拍脑袋，排出来的顺序既说不清权衡，也挡不住临时插单。这个技能把 Scrum 里的产品负责人工作拆成可重复流程，让故事、验收标准、工作量、优先级和冲刺承诺能对上。

核心工作方式

用户故事生成：先识别 persona，再写动作、价值和 Given-When-Then 验收标准，用 Fibonacci 估算点数，最后按 INVEST 校验：独立、可协商、有价值、可估算、小到一次冲刺内完成、可测试。
验收标准按规模约束：1-2 点至少 3-4 条，3-5 点 4-6 条，8 点 5-8 条；13+ 点应拆分。检查项覆盖正常路径、输入校验、错误处理、性能和可访问性。
Epic 拆分：按流程步骤、角色、数据类型、CRUD 操作或 happy path 优先拆分；每个故事需交付独立价值，且点数不超过 8。
冲刺规划：容量按 velocity × availability factor 计算，常见可用系数从 1.0 到 0.7 覆盖休假、节假日和多人缺勤；承诺填满 80-85% 容量，另设 10-15% stretch goals，再识别依赖和风险并拆任务。
优先级权重固定：Business Value 40%、User Impact 30%、Risk/Dependencies 15%、Effort 15%，Critical 立即处理，High 进入本冲刺，Medium 看后续 2-3 个迭代，Low 留在待办。
度量与完成定义：跟踪 velocity 是否稳定在 ±10%、承诺达成率是否 >85%、中途范围变更是否 <10%、结转是否 <15%；完成标准包括代码评审、单元测试、验收标准验证、文档、staging 部署和 PO 验收。

适用边界

它适合作为 Scrum 团队的结构化决策助手：故事质量、容量估算和优先级解释仍需结合真实业务上下文。安全上不自动安装依赖、修改系统权限、创建持久化任务或执行下载内容；涉及发送、发布、删除、付款、部署等外部写入时，应先展示目标和影响并获得明确确认。凭据只用于用户指定的官方服务，不回显、不记录、不转发；命令和代码默认作为参考，只有在目标范围清楚且用户明确要求时才可运行。完整模板见 references/user-story-templates.md，规划细节见 references/sprint-planning-guide.md。