迭代计划

sprint-plan

分类通用

作者Alireza Rezvani

许可MIT

评分4.60/5

使用5.6K

/sprint-plan

为 $ARGUMENTS 创建 Sprint 计划，包含明确的容量计算、结转检查和 Ready 定义 (DoR) 门禁。$ARGUMENTS 的前几个 token 为 Sprint 目标；末尾的数字被视为团队容量（故事点或人天）。如果未提供容量，请在第一阶段进行计算 —— 切勿凭空捏造。

用法

bash

/sprint-plan <goal> [capacity]
例如：/sprint-plan "Checkout v2 ready for beta" 34

第一阶段 —— 容量计算（执行计算并展示过程）

1. 原始容量 = 团队人数 × Sprint 工作日 × 专注系数（默认 0.7；若未知请询问）
2. 扣除项 —— 逐行明确减去：节假日/年假、On-call/支持轮值、仪式时间（约 10%）、已知干扰项
3. 速率交叉检查 —— 与过去 3 个 Sprint 的*已完成*（而非承诺）点数的滚动平均值进行比较。如果计算出的容量超过滚动速率 15% 以上，请按滚动速率进行计划并予以说明。

输出一个小表格：原始容量 $\rightarrow$ 扣除项 $\rightarrow$ 净容量 $\rightarrow$ 滚动速率 $\rightarrow$ 计划数值。

第二阶段 —— 结转检查（在添加新任务之前）

1. 列出所有从上个 Sprint 结转的项目（在 Sprint 结束时未完成的任务）
2. 重新评估*剩余*工作量 —— 切勿直接沿用原始估值
3. 结转项优先占用容量；新范围仅占用剩余容量
4. 如果结转项超过容量的 ~30%，将其标记为系统性过度承诺信号，并建议本 Sprint 减少承诺量，而非加大压力

第三阶段 —— Ready 定义 (DoR) 门禁（针对每个 Story）

只有在满足所有以下条件时，Story 才能进入承诺范围 —— 否则将其放入“需要细化”列表，而非 Sprint 中：

[ ] 用户故事具有明确的角色、动作和结果（符合 INVEST 原则）

[ ] 验收标准已编写且可测试

[ ] 由团队评估（而非仅由计划者评估）

[ ] 依赖项已识别，且已解决或已排期

[ ] 规模足够小，能在 Sprint 内完成（否则请拆分）

通过以下脚本从 Epic 生成经过 INVEST 检查的故事：

bash

python3 product-team/agile-product-owner/skills/agile-product-owner/scripts/user_story_generator.py

第四阶段 —— 输出结构

Sprint 目标 —— 一句话概括；所有承诺的任务必须服务于此目标

容量表 —— 来自第一阶段

结转项 —— 来自第二阶段，在承诺范围内优先列出

承诺范围 —— 通过 DoR 门禁的故事，总和 $\le$ 计划数值

挑战范围 (Stretch scope) —— 明确区分；仅在承诺范围完成后才启动

风险与依赖 —— 需注明负责人

DoR 例外 —— 如果严格执行门禁则为空；否则请为每项例外提供理由

仓库资源（已验证路径）

Skill: product-team/agile-product-owner/skills/agile-product-owner/SKILL.md

Sprint 计划模板: product-team/agile-product-owner/skills/agile-product-owner/assets/sprint_planning_template.md

Sprint 计划指南: product-team/agile-product-owner/skills/agile-product-owner/references/sprint-planning-guide.md

Story 生成器: product-team/agile-product-owner/skills/agile-product-owner/scripts/user_story_generator.py