agile-product-owner

Agile Product Owner

面向产品负责人的 Backlog 管理与 Sprint 执行工具包，涵盖用户故事生成、验收标准模式、Sprint 规划和速度追踪。

---

目录

• 本技能的独特之处
• 用户故事生成工作流
• 验收标准模式
• Epic 拆分工作流
• Sprint 规划工作流
• Backlog 优先级排序
• 参考文档
• 工具

---

本技能的独特之处

• 贴合实际的容量计算： Sprint 容量基于速度 × 可用系数，而非凭空估计。
• 按故事规模确定验收标准数量： 最少验收标准数量与故事点数对应，避免大型条目规格不足。
• 一致的加权优先级排序： 价值 40%、影响 30%、风险 15%、工作量 15%，使取舍过程保持透明。
• 系统化的 Epic 拆分技术： 五种具体的拆分模式，防止故事过大。
• 内置 INVEST 验证： 每个工作流都包含验证步骤，而不仅仅是指导建议。

用户故事生成工作流

根据需求创建符合 INVEST 原则的用户故事：

1. 确定角色（谁将从该功能中受益）
2. 定义所需的操作或能力
3. 阐明所交付的收益或价值
4. 使用 Given-When-Then 编写验收标准
5. 使用斐波那契数列估算故事点
6. 对照 INVEST 标准进行验证
7. 添加到 Backlog 并设定优先级
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.

故事类型

类型	模板	示例
功能	作为[角色]，我希望[操作]，以便[收益]	作为用户，我希望筛选搜索结果，以便更快找到条目
改进	作为[角色]，我需要[能力]，以实现[目标]	作为用户，我需要更快的页面加载速度，以便无挫败感地完成任务
缺陷修复	作为[角色]，当[条件]时，我期望[行为]	作为用户，我期望刷新页面后购物车内容依然保留
使能类	作为开发者，我需要完成[技术任务]，以实现[能力]	作为开发者，我需要实现缓存，以实现即时搜索

角色参考

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

---

验收标准模式

使用 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.

验收标准检查清单

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

类别	示例
正常路径	给定有效输入，当提交时，则显示成功提示
校验	当必填字段为空时，应拒绝输入
错误处理	当 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 影响的所有角色（persona）
3. 列出每个角色所需的全部能力
4. 将能力归类为合理的 Story
5. 验证每个 Story 不超过 8 点
6. 识别 Story 之间的依赖关系
7. 排列 Story 顺序，以便增量交付
8. 验证： 每个 Story 都能独立交付价值；所有 Story 合起来覆盖 Epic 范围

拆分技巧

技巧	适用场景	示例
按工作流步骤	线性流程	"结账" → "加入购物车" + "输入支付信息" + "确认订单"
按角色	存在多种用户类型	"仪表盘" → "管理员仪表盘" + "用户仪表盘"
按数据类型	存在多种输入	"导入" → "导入 CSV" + "导入 Excel"
按操作	CRUD 功能	"管理用户" → "创建" + "编辑" + "删除"
优先主流程	降低风险	"功能" → "基本流程" + "错误处理" + "边界情况"

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 标准验证

加入 Sprint 前，逐一验证每个 Story：

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

---

参考文档

用户 Story 模板

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

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

冲刺规划指南

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

完成定义

故事满足以下条件时视为完成：

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