agile-product-owner

敏捷产品负责人

面向产品负责人的待办事项管理与冲刺执行工具包，包括用户故事生成、验收标准模式、冲刺规划和速率跟踪。

---

目录

• 用户故事生成工作流
• 验收标准模式
• Epic 拆分工作流
• 冲刺规划工作流
• 待办事项优先级排序
• 参考文档
• 工具

---

先明确需求

生成故事或冲刺计划前，先确认以下输入。如果缺少某项或描述含糊，且会影响结果，请先询问；如果不会影响结果，则采用合理的默认值并说明所用的默认值。

• **受益的角色：**故事服务的具体用户（决定“作为……”这一条款和验收标准）。
• **需求或 Epic 范围：**所需能力及其成功条件（决定故事拆分和 INVEST 验证）。
• **团队速率和可用时间：**滚动平均故事点数，以及本次冲刺中的带薪休假（PTO）/节假日（确定承诺容量与弹性容量）。

只询问本次请求中最重要的两三项输入，不必询问完整清单。如果用户希望立即获得结果，请直接生成，并在开头说明假设。

用户故事生成工作流

根据需求创建符合 INVEST 标准的用户故事：

1. 确定角色（谁会从此功能中受益）
2. 定义所需操作或能力
3. 阐明所带来的收益或价值
4. 使用 Given-When-Then 编写验收标准
5. 使用斐波那契数列估算故事点数
6. 根据 INVEST 标准进行验证
7. 按优先级加入待办事项
8. **验证：**故事符合所有 INVEST 标准；验收标准可测试

用户故事模板

As a [persona],
I want to [action/capability],
So that [benefit/value].

示例：

As a marketing manager,
I want to export campaign reports to PDF,
So that I can share results with stakeholders who don't have system access.

故事类型

类型	模板	示例
功能	作为 [角色]，我想要 [操作]，以便 [收益]	作为用户，我想要筛选搜索结果，以便更快找到所需条目
改进	作为 [角色]，我需要 [能力] 来 [目标]	作为用户，我需要更快的页面加载速度，以便顺畅完成任务
Bug 修复	作为 [角色]，我期望在 [条件] 下出现 [行为]	作为用户，我期望刷新页面后购物车内容仍然保留
使能项	作为开发者，我需要 [技术任务]，以实现 [能力]	作为开发者，我需要实现缓存，以支持即时搜索

角色参考

角色	典型需求	场景
终端用户	效率、简洁、可靠性	日常使用功能
管理员	控制、可见性、安全性	系统管理
高级用户	自动化、自定义、快捷方式	专业工作流
新用户	指引、学习、安全性	入门引导

---

验收标准模式

使用 Given-When-Then 格式编写可测试的验收标准。

Given-When-Then 模板

Given [precondition/context],
When [action/trigger],
Then [expected outcome].

示例：

Given the user is logged in with valid credentials,
When they click the "Export" button,
Then a PDF download starts within 2 seconds.

Given the user has entered an invalid email format,
When they submit the registration form,
Then an inline error message displays "Please enter a valid email address."

Given the shopping cart contains items,
When the user refreshes the browser,
Then the cart contents remain unchanged.

验收标准检查清单

每个故事都应包含以下类别的标准：

类别	示例
正常流程	Given 输入有效，When 提交，Then 显示成功消息
验证	必填字段为空时，应拒绝输入
错误处理	API 调用失败时，必须显示用户易懂的消息
性能	操作应在 2 秒内完成
无障碍访问	必须能够仅使用键盘进行导航

不同故事规模的最低标准数

故事点数	最低验收标准数量
1-2	3-4 条标准
3-5	4-6 条标准
8	5-8 条标准
13+	拆分故事

完整模板库请参阅 references/user-story-templates.md。

---

Epic 拆分工作流

将 Epic 拆分为可在一个 Sprint 内交付的 Story：

1. 定义 Epic 范围和成功标准
2. 确定受 Epic 影响的所有角色
3. 列出每个角色所需的所有能力
4. 将能力归纳为逻辑清晰的 Story
5. 验证每个 Story 的点数 ≤8
6. 确定 Story 之间的依赖关系
7. 按照增量交付的顺序安排 Story
8. 验证： 每个 Story 都能独立创造价值；所有 Story 覆盖 Epic 范围

Story 拆分决策逻辑

按顺序应用以下规则。使用第一个符合 Story 情况的规则：

#	拆分规则	适用情况	拆分方式
1	工作流步骤	Story 包含多个连续步骤	将每个步骤作为独立的 Story
2	业务规则变体	Story 引入了规则变体（例如，定价层级、用户角色）	将每种规则变体作为独立的 Story
3	数据变体	Story 处理不同的数据类型或格式	将每种数据类型作为独立的 Story
4	复杂的验收标准	Story 有 8 个或更多验收标准，涵盖不同的行为	将每个不同的行为类别作为独立的 Story
5	工作量较大	Story 需要大量开发工作（13 点或更多）	按工作量里程碑拆分（基础 → 功能 → 润色）
6	外部依赖	Story 依赖外部 API、团队或审批	将有依赖的工作和独立工作拆分为不同的 Story
7	DevOps 工作量	Story 需要大量基础设施工作	将基础设施设置与功能实现拆分
8	均不适用	Story 本身较小但不够明确	使用微型探索任务（TAD）——用于降低不确定性的小型探索任务

拆分输出格式

对于每次拆分，请记录：

## Original Story
As a [persona], I want to [action] so that [benefit].
Points: 13 | Status: Too large for sprint

## Suggested Splits

### Split 1: By Workflow Steps
- **Story A:** As a [persona], I want to [step 1] so that [partial benefit].
  Points: 5 | Independently valuable: Yes
- **Story B:** As a [persona], I want to [step 2] so that [remaining benefit].
  Points: 5 | Independently valuable: Yes

### Risks & Tradeoffs
- [What coupling exists between the split stories]
- [What is lost by delivering them separately]

### Implementation Order
1. Story A (foundation) → 2. Story B (builds on A)

拆分技巧（快速参考）

技巧	使用场景	示例
按工作流步骤	线性流程	“结账” → “加入购物车” + “输入付款信息” + “确认订单”
按角色	多种用户类型	“仪表板” → “管理员仪表板” + “用户仪表板”
按数据类型	多种输入	“导入” → “导入 CSV” + “导入 Excel”
按操作	CRUD 功能	“管理用户” → “创建” + “编辑” + “删除”
按业务规则	规则变体	“折扣” → “百分比折扣” + “固定折扣” + “买一送一”
先实现正常流程	降低风险	“功能” → “基本流程” + “错误处理” + “边缘情况”
按依赖关系	外部阻碍因素	“集成” → “模拟集成” + “实时集成”
微型探索任务	高度不确定	“AI 功能” → “探索：可行性” + “MVP 实现”

Epic 示例

Epic： 用户仪表板

拆分：

Epic: User Dashboard (34 points total)
├── US-001: View key metrics (5 pts) - End User
├── US-002: Customize layout (5 pts) - Power User
├── US-003: Export data to CSV (3 pts) - End User
├── US-004: Share with team (5 pts) - End User
├── US-005: Set up alerts (5 pts) - Power User
├── US-006: Filter by date range (3 pts) - End User
├── US-007: Admin overview (5 pts) - Admin
└── US-008: Enable caching (3 pts) - Enabler

---

Sprint 规划工作流

规划 Sprint 容量并选择 Story：

1. 计算团队容量（速度 × 可用性）
2. 与利益相关者审查 Sprint 目标
3. 从已排序的待办事项中选择 Story
4. 填充至容量的 80-85%（承诺工作）
5. 添加延展目标（额外 10-15%）
6. 确定依赖关系和风险
7. 将复杂的 Story 拆分为任务
8. 验证： 承诺点数 ≤容量的 85%；所有 Story 均有验收标准

容量计算

Sprint Capacity = Average Velocity × Availability Factor

Example:
Average Velocity: 30 points
Team availability: 90% (one member partially out)
Adjusted Capacity: 27 points

Committed: 23 points (85% of 27)
Stretch: 4 points (15% of 27)

可用性系数

情况	系数
完整 Sprint，无带薪休假	1.0
一名团队成员有 50% 时间缺席	0.9
Sprint 期间有假日	0.8
多名成员缺席	0.7

Sprint 工作量模板

Sprint Capacity: 27 points
Sprint Goal: [Clear, measurable objective]

COMMITTED (23 points):
[H] US-001: User dashboard (5 pts)
[H] US-002: Export feature (3 pts)
[H] US-003: Search filter (5 pts)
[M] US-004: Settings page (5 pts)
[M] US-005: Help tooltips (3 pts)
[L] US-006: Theme options (2 pts)

STRETCH (4 points):
[L] US-007: Sort options (2 pts)
[L] US-008: Print view (2 pts)

完整的规划流程请参阅 references/sprint-planning-guide.md。

---

待办事项优先级排序

根据价值和工作量评估对待办事项进行排序。

优先级

优先级	定义	Sprint 目标
严重	阻碍用户、安全问题、数据丢失	立即处理
高	核心功能、关键用户需求	本 Sprint
中	改进、增强功能	接下来的 2-3 个 Sprint
低	有则更好、细微改进	待办事项

优先级因素

因素	权重	问题
业务价值	40%	对收入有何影响？用户需求如何？是否符合战略方向？
用户影响	30%	涉及多少用户？使用频率如何？
风险／依赖项	15%	技术风险如何？是否依赖外部因素？
工作量	15%	规模如何？复杂度如何？不确定性如何？

INVEST 标准验证

将故事加入冲刺前，请逐项验证：

标准	问题	通过条件……
Independent（独立）	能否在不依赖其他尚未承诺的故事的情况下开发？	没有阻塞性依赖项
Negotiable（可协商）	实现方式是否灵活？	存在多种可行方案
Valuable（有价值）	是否能为用户或业务带来价值？	“以便……”部分明确说明收益
Estimable（可估算）	团队能否估算该故事？	对故事已有足够了解，可以评估规模
Small（小型）	能否在一个冲刺内完成？	≤8 个故事点
Testable（可测试）	能否验证该故事已完成？	验收标准明确

---

参考文档

用户故事模板

references/user-story-templates.md 包含：

• 按类型划分的标准故事格式（功能、改进、错误修复、使能项）
• 验收标准模式（Given-When-Then、Should/Must/Can）
• INVEST 标准验证清单
• 故事点估算指南（斐波那契数列）
• 常见故事反模式及修正方法
• 故事拆分技巧

冲刺规划指南

references/sprint-planning-guide.md 包含：

• 冲刺规划会议议程
• 容量计算公式
• 待办事项优先级框架（WSJF）
• 冲刺仪式指南（站会、评审、回顾）
• 速率跟踪与燃尽图模式
• 完成定义清单
• 冲刺指标与目标

---

工具

用户故事生成器

# Generate stories from sample epic
python scripts/user_story_generator.py

# Plan sprint with capacity
python scripts/user_story_generator.py sprint 30

生成：

• 符合 INVEST 标准的用户故事
• Given-When-Then 验收标准
• 故事点估算（斐波那契数列）
• 优先级分配
• 冲刺任务安排，包括已承诺项和延展项

输出示例

USER STORY: USR-001
========================================
Title: View Key Metrics
Type: story
Priority: HIGH
Points: 5

Story:
As a End User, I want to view key metrics and KPIs
so that I can save time and work more efficiently

Acceptance Criteria:
  1. Given user has access, When they view key metrics, Then the result is displayed
  2. Should validate input before processing
  3. Must show clear error message when action fails
  4. Should complete within 2 seconds
  5. Must be accessible via keyboard navigation

INVEST Checklist:
  ✓ Independent
  ✓ Negotiable
  ✓ Valuable
  ✓ Estimable
  ✓ Small
  ✓ Testable

---

冲刺指标

跟踪冲刺健康状况和团队表现。

关键指标

指标	公式	目标
速率	已完成点数 / 冲刺	稳定在 ±10% 以内
承诺可靠性	已完成 / 已承诺	>85%
范围变更	冲刺中途增加或移除的点数	<10%
结转	未完成的点数	<15%

速率跟踪

Sprint 1: 25 points
Sprint 2: 28 points
Sprint 3: 30 points
Sprint 4: 32 points
Sprint 5: 29 points
------------------------
Average Velocity: 28.8 points
Trend: Stable

Planning: Commit to 24-26 points

完成定义

故事在满足以下条件时即告完成：

• 代码完成并经过同行评审
• 已编写并通过单元测试
• 已验证验收标准
• 文档已更新
• 已部署到预发布环境
• 产品负责人已验收
• 没有遗留严重错误

---

工具参考

user_story_generator.py

从示例史诗生成符合 INVEST 标准的用户故事，包括验收标准、故事点估算、优先级分配和冲刺规划。

参数	类型	默认值	描述
sprint	子命令	-	以冲刺规划模式运行
[capacity]	int	30	冲刺容量，以故事点计（与 sprint 一起使用）

# Generate stories from sample epic
python scripts/user_story_generator.py

# Sprint planning with capacity
python scripts/user_story_generator.py sprint 30
python scripts/user_story_generator.py sprint 45

输出包括：

• 故事 ID、标题、类型、优先级和点数估算
• “作为……我想要……以便……”格式的用户故事叙述
• 每个故事的 5 项验收标准（Given-When-Then、验证、错误、性能、无障碍）
• 每个故事的 INVEST 标准检查清单
• 按优先级细分的待办事项摘要
• 冲刺任务安排，包括已承诺项和延展项（冲刺模式下）

故障排除

问题	原因	解决方案
故事过大（>8 点）	Epic 拆分得不够细	运用拆分技巧：按工作流步骤、角色或 CRUD 操作拆分
验收标准无法测试	标准使用了模糊措辞	使用 Given-When-Then 格式重写，并明确具体、可观察的结果
反复未能完成 Sprint 承诺	速度尚未稳定或承诺过于激进	跟踪 3 个以上 Sprint 的速度；承诺完成滚动平均值的 80-85%
搁置到下个 Sprint 的故事过多	Sprint 中途变更范围或估算不准确	执行禁止变更范围的规则；使用规划扑克校准估算
故事缺少明确价值	缺少「以便」的收益说明	确认每个故事都回答：谁会受益、能获得什么，以及这为何重要
Sprint 依赖项过多	故事不够独立	重新排列待办事项；将有依赖关系的故事拆分为独立切片
利益相关者对优先级有争议	缺少客观的优先级排序框架	使用 WSJF 或价值/工作量评分；记录决策依据

---

成功标准

标准	目标	衡量方式
承诺可靠性	完成 >85% 的承诺点数	每个 Sprint 完成的点数 / 承诺的点数
INVEST 合规性	100% 的故事通过全部 6 项标准	user_story_generator INVEST 检查清单
速度稳定性	在滚动平均值的 +/-10% 范围内	跟踪 5 个以上 Sprint 的速度趋势
范围变更	Sprint 中途新增/移除的点数 <10%	统计规划后新增或移除的点数
搁置率	<15% 的承诺点数	未完成的点数 / 承诺的点数
验收标准质量	所有标准均可测试并经过验证	Sprint 开始前由 QA 签署验收标准
待办事项梳理	待办事项中始终有 2 个 Sprint 的内容准备就绪	统计已细化且包含验收标准的故事数量

---

范围与限制

范围内：

• 生成用户故事并使用 INVEST 进行验证
• 使用 Given-When-Then 格式编写验收标准
• 根据团队容量规划 Sprint 工作量
• 将 Epic 拆分为适合 Sprint 的故事
• 待办事项优先级排序框架（WSJF、价值/工作量）
• 速度跟踪与 Sprint 指标
• 强制执行完成定义

范围外：

• 创建 Jira/Linear 工单（使用 JSON 导出及其 API）
• 可视化燃尽图（使用项目管理工具的仪表板）
• 分配团队成员及按个人计算容量
• 跨团队依赖关系管理（使用项目级工具）
• 超出季度周期的发布规划
• 自动生成验收测试（参见工程技能）

---

集成点

工具 / 平台	集成方式	用例
Jira / Linear	复制故事输出，或扩展脚本以导出 JSON	将生成的故事导入为工单
Confluence / Notion	粘贴适合阅读的输出	记录 Sprint 计划和待办事项
Slack	分享 Sprint 规划摘要	异步沟通 Sprint 启动信息
product-manager-toolkit	RICE 评分为故事优先级提供依据	使 Sprint 优先级与产品策略保持一致
product-strategist	OKR 分解为 Epic 选择提供依据	将 Sprint 工作与季度目标关联起来
ux-researcher-designer	角色数据为故事中的角色设定提供依据	让用户故事以研究支持的角色为基础