Agile Product Owner
Backlog management and sprint execution toolkit for product owners, including user story generation, acceptance criteria patterns, sprint planning, and velocity tracking.
Table of Contents
User Story Generation Workflow
Create INVEST-compliant user stories from requirements:
- 1. Identify the persona (who benefits from this feature)
- Define the action or capability needed
- Articulate the benefit or value delivered
- Write acceptance criteria using Given-When-Then
- Estimate story points using Fibonacci scale
- Validate against INVEST criteria
- Add to backlog with priority
- Validation: Story passes all INVEST criteria; acceptance criteria are testable
User Story Template
CODEBLOCK0
Example:
CODEBLOCK1
Story Types
| Type | Template | Example |
|---|
| Feature | As a [persona], I want to [action] so that [benefit] | As a user, I want to filter search results so that I find items faster |
| Improvement |
As a [persona], I need [capability] to [goal] | As a user, I need faster page loads to complete tasks without frustration |
| Bug Fix | As a [persona], I expect [behavior] when [condition] | As a user, I expect my cart to persist when I refresh the page |
| Enabler | As a developer, I need to [technical task] to enable [capability] | As a developer, I need to implement caching to enable instant search |
Persona Reference
| Persona | Typical Needs | Context |
|---|
| End User | Efficiency, simplicity, reliability | Daily feature usage |
| Administrator |
Control, visibility, security | System management |
| Power User | Automation, customization, shortcuts | Expert workflows |
| New User | Guidance, learning, safety | Onboarding |
Acceptance Criteria Patterns
Write testable acceptance criteria using Given-When-Then format.
Given-When-Then Template
CODEBLOCK2
Examples:
CODEBLOCK3
Acceptance Criteria Checklist
Each story should include criteria for:
| Category | Example |
|---|
| Happy Path | Given valid input, When submitted, Then success message displayed |
| Validation |
Should reject input when required field is empty |
| Error Handling | Must show user-friendly message when API fails |
| Performance | Should complete operation within 2 seconds |
| Accessibility | Must be navigable via keyboard only |
Minimum Criteria by Story Size
| Story Points | Minimum AC Count |
|---|
| 1-2 | 3-4 criteria |
| 3-5 |
4-6 criteria |
| 8 | 5-8 criteria |
| 13+ | Split the story |
See references/user-story-templates.md for complete template library.
Epic Breakdown Workflow
Break epics into deliverable sprint-sized stories:
- 1. Define epic scope and success criteria
- Identify all personas affected by the epic
- List all capabilities needed for each persona
- Group capabilities into logical stories
- Validate each story is ≤8 points
- Identify dependencies between stories
- Sequence stories for incremental delivery
- Validation: Each story delivers standalone value; total stories cover epic scope
Splitting Techniques
| Technique | When to Use | Example |
|---|
| By workflow step | Linear process | "Checkout" → "Add to cart" + "Enter payment" + "Confirm order" |
| By persona |
Multiple user types | "Dashboard" → "Admin dashboard" + "User dashboard" |
| By data type | Multiple inputs | "Import" → "Import CSV" + "Import Excel" |
| By operation | CRUD functionality | "Manage users" → "Create" + "Edit" + "Delete" |
| Happy path first | Risk reduction | "Feature" → "Basic flow" + "Error handling" + "Edge cases" |
Epic Example
Epic: User Dashboard
Breakdown:
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 Planning Workflow
Plan sprint capacity and select stories:
- 1. Calculate team capacity (velocity × availability)
- Review sprint goal with stakeholders
- Select stories from prioritized backlog
- Fill to 80-85% of capacity (committed)
- Add stretch goals (10-15% additional)
- Identify dependencies and risks
- Break complex stories into tasks
- Validation: Committed points ≤85% capacity; all stories have acceptance criteria
Capacity Calculation
CODEBLOCK5
Availability Factors
| Scenario | Factor |
|---|
| Full sprint, no PTO | 1.0 |
| One team member out 50% |
0.9 |
| Holiday during sprint | 0.8 |
| Multiple members out | 0.7 |
Sprint Loading Template
CODEBLOCK6
See references/sprint-planning-guide.md for complete planning procedures.
Backlog Prioritization
Prioritize backlog using value and effort assessment.
Priority Levels
| Priority | Definition | Sprint Target |
|---|
| Critical | Blocking users, security, data loss | Immediate |
| High |
Core functionality, key user needs | This sprint |
| Medium | Improvements, enhancements | Next 2-3 sprints |
| Low | Nice-to-have, minor improvements | Backlog |
Prioritization Factors
| Factor | Weight | Questions |
|---|
| Business Value | 40% | Revenue impact? User demand? Strategic alignment? |
| User Impact |
30% | How many users? How frequently used? |
| Risk/Dependencies | 15% | Technical risk? External dependencies? |
| Effort | 15% | Size? Complexity? Uncertainty? |
INVEST Criteria Validation
Before adding to sprint, validate each story:
| Criterion | Question | Pass If... |
|---|
| Independent | Can this be developed without other uncommitted stories? | No blocking dependencies |
| Negotiable |
Is the implementation flexible? | Multiple approaches possible |
|
Valuable | Does this deliver user or business value? | Clear benefit in "so that" |
|
Estimable | Can the team estimate this? | Understood well enough to size |
|
Small | Can this complete in one sprint? | ≤8 story points |
|
Testable | Can we verify this is done? | Clear acceptance criteria |
Reference Documentation
User Story Templates
INLINECODE2 contains:
- - Standard story formats by type (feature, improvement, bug fix, enabler)
- Acceptance criteria patterns (Given-When-Then, Should/Must/Can)
- INVEST criteria validation checklist
- Story point estimation guide (Fibonacci scale)
- Common story antipatterns and fixes
- Story splitting techniques
Sprint Planning Guide
INLINECODE3 contains:
- - Sprint planning meeting agenda
- Capacity calculation formulas
- Backlog prioritization framework (WSJF)
- Sprint ceremony guides (standup, review, retro)
- Velocity tracking and burndown patterns
- Definition of Done checklist
- Sprint metrics and targets
Tools
User Story Generator
CODEBLOCK7
Generates:
- - INVEST-compliant user stories
- Given-When-Then acceptance criteria
- Story point estimates (Fibonacci scale)
- Priority assignments
- Sprint loading with committed and stretch items
Sample Output
CODEBLOCK8
Sprint Metrics
Track sprint health and team performance.
Key Metrics
| Metric | Formula | Target |
|---|
| Velocity | Points completed / sprint | Stable ±10% |
| Commitment Reliability |
Completed / Committed | >85% |
| Scope Change | Points added or removed mid-sprint | <10% |
| Carryover | Points not completed | <15% |
Velocity Tracking
CODEBLOCK9
Definition of Done
Story is complete when:
- - [ ] Code complete and peer reviewed
- [ ] Unit tests written and passing
- [ ] Acceptance criteria verified
- [ ] Documentation updated
- [ ] Deployed to staging environment
- [ ] Product Owner accepted
- [ ] No critical bugs remaining
敏捷产品负责人
面向产品负责人的待办事项管理与冲刺执行工具包,包含用户故事生成、验收标准模式、冲刺规划和速度跟踪功能。
目录
用户故事生成工作流
根据需求创建符合INVEST标准的用户故事:
- 1. 确定用户角色(谁将从该功能中受益)
- 定义所需操作或能力
- 阐述所交付的收益或价值
- 使用给定-当-那么格式编写验收标准
- 使用斐波那契数列估算故事点数
- 对照INVEST标准进行验证
- 按优先级添加到待办事项列表
- 验证: 故事通过所有INVEST标准;验收标准可测试
用户故事模板
作为[用户角色],
我想要[操作/能力],
以便[收益/价值]。
示例:
作为市场经理,
我想要将营销活动报告导出为PDF,
以便与没有系统访问权限的利益相关者分享结果。
故事类型
| 类型 | 模板 | 示例 |
|---|
| 功能 | 作为[用户角色],我想要[操作]以便[收益] | 作为用户,我想要筛选搜索结果以便更快找到项目 |
| 改进 |
作为[用户角色],我需要[能力]以达成[目标] | 作为用户,我需要更快的页面加载以无挫败地完成任务 |
| 缺陷修复 | 作为[用户角色],我期望在[条件]下出现[行为] | 作为用户,我期望刷新页面时购物车内容保持不变 |
| 使能器 | 作为开发者,我需要[技术任务]以支持[能力] | 作为开发者,我需要实现缓存以支持即时搜索 |
用户角色参考
| 用户角色 | 典型需求 | 场景 |
|---|
| 最终用户 | 效率、简洁、可靠 | 日常功能使用 |
| 管理员 |
控制、可见性、安全 | 系统管理 |
| 高级用户 | 自动化、定制化、快捷方式 | 专家工作流 |
| 新用户 | 引导、学习、安全 | 入门体验 |
验收标准模式
使用给定-当-那么格式编写可测试的验收标准。
给定-当-那么模板
给定[前提条件/上下文],
当[操作/触发条件],
那么[预期结果]。
示例:
给定用户已使用有效凭据登录,
当他们点击导出按钮,
那么PDF下载应在2秒内开始。
给定用户输入了无效的邮箱格式,
当他们提交注册表单,
那么内联错误消息应显示请输入有效的邮箱地址。
给定购物车中包含商品,
当用户刷新浏览器,
那么购物车内容应保持不变。
验收标准检查清单
每个故事应包含以下类别的标准:
| 类别 | 示例 |
|---|
| 正常路径 | 给定有效输入,当提交时,那么显示成功消息 |
| 验证 |
当必填字段为空时应拒绝输入 |
| 错误处理 | 当API失败时必须显示用户友好消息 |
| 性能 | 应在2秒内完成操作 |
| 无障碍 | 必须仅通过键盘即可导航 |
按故事规模的最低标准
4-6条标准 |
| 8 | 5-8条标准 |
| 13+ | 拆分故事 |
完整模板库请参见 references/user-story-templates.md。
史诗拆解工作流
将史诗拆解为可交付的冲刺规模故事:
- 1. 定义史诗范围和成功标准
- 确定受史诗影响的所有用户角色
- 列出每个用户角色所需的所有能力
- 将能力分组为逻辑故事
- 验证每个故事点数≤8
- 识别故事之间的依赖关系
- 按增量交付顺序排列故事
- 验证: 每个故事交付独立价值;所有故事覆盖史诗范围
拆分技巧
| 技巧 | 使用时机 | 示例 |
|---|
| 按工作流步骤 | 线性流程 | 结账 → 加入购物车 + 输入支付信息 + 确认订单 |
| 按用户角色 |
多种用户类型 | 仪表盘 → 管理员仪表盘 + 用户仪表盘 |
| 按数据类型 | 多种输入 | 导入 → 导入CSV + 导入Excel |
| 按操作 | CRUD功能 | 管理用户 → 创建 + 编辑 + 删除 |
| 先正常路径 | 降低风险 | 功能 → 基本流程 + 错误处理 + 边界情况 |
史诗示例
史诗: 用户仪表盘
拆解:
史诗:用户仪表盘(总计34点)
├── US-001:查看关键指标(5点)- 最终用户
├── US-002:自定义布局(5点)- 高级用户
├── US-003:导出数据为CSV(3点)- 最终用户
├── US-004:与团队分享(5点)- 最终用户
├── US-005:设置提醒(5点)- 高级用户
├── US-006:按日期范围筛选(3点)- 最终用户
├── US-007:管理员概览(5点)- 管理员
└── US-008:启用缓存(3点)- 使能器
冲刺规划工作流
规划冲刺容量并选择故事:
- 1. 计算团队容量(速度 × 可用性)
- 与利益相关者评审冲刺目标
- 从已排序的待办事项列表中选择故事
- 填充至容量的80-85%(承诺项)
- 添加延伸目标(额外10-15%)
- 识别依赖关系和风险
- 将复杂故事拆解为任务
- 验证: 承诺点数≤85%容量;所有故事都有验收标准
容量计算
冲刺容量 = 平均速度 × 可用性因子
示例:
平均速度:30点
团队可用性:90%(一名成员部分缺席)
调整后容量:27点
承诺项:23点(27的85%)
延伸目标:4点(27的15%)
可用性因子
| 场景 | 因子 |
|---|
| 完整冲刺,无休假 | 1.0 |
| 一名团队成员50%缺席 |
0.9 |
| 冲刺期间有假期 | 0.8 |
| 多名成员缺席 | 0.7 |
冲刺加载模板
冲刺容量:27点
冲刺目标:[清晰、可衡量的目标]
承诺项(23点):
[H] US-001:用户仪表盘(5点)
[H] US-002:导出功能(3点)
[H] US-003:搜索筛选(5点)
[M] US-004:设置页面(5点)
[M] US-005:帮助提示(3点)
[L] US-006:主题选项(2点)
延伸目标(4点):
[L] US-007:排序选项(2点)
[L] US-008:打印视图(2点)
完整规划流程请参见 references/sprint-planning-guide.md。
待办事项优先级排序
使用价值和努力评估对待办事项进行优先级排序。
优先级级别
| 优先级 | 定义 | 冲刺目标 |
|---|
| 关键 | 阻塞用户、安全问题、数据丢失 | 立即 |
| 高 |
核心功能、关键用户需求 | 本冲刺 |
| 中 | 改进、增强 | 接下来2-3个冲刺 |
| 低 | 锦上添花、微小改进 | 待办事项列表 |
优先级排序因素
| 因素 | 权重 | 问题 |
|---|
| 业务价值 | 40% | 收入影响?用户需求?战略一致性? |
| 用户影响 |
30% | 影响多少用户?使用频率? |
| 风险/依赖 | 15% | 技术风险?外部依赖? |
| 努力 | 15% | 规模?复杂度?不确定性? |
INVEST标准验证
在添加到冲刺前,验证每个故事:
| 标准 | 问题 | 通过条件 |
|---|
| I独立 | 能否在无其他未承诺故事的情况下开发? | 无阻塞性依赖 |
| N可协商 |
实现方式是否灵活? | 存在多种方法 |