agile-product-owner
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseAgile Product Owner
Agile 产品负责人
Backlog management and sprint execution toolkit for product owners, including user story generation, acceptance criteria patterns, sprint planning, and velocity tracking.
面向产品负责人的 Backlog 管理与 Sprint 执行工具包，包括 User Story 生成、Acceptance Criteria 模板、Sprint 规划以及速度跟踪。
Table of Contents
目录
User Story Generation Workflow
User Story 生成流程
Create INVEST-compliant user stories from requirements:
- 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
根据需求创建符合 INVEST 标准的 User Story：
- 确定 Persona（谁将从该功能中受益）
- 定义所需的操作或能力
- 明确带来的收益或价值
- 使用 Given-When-Then 格式编写 Acceptance Criteria
- 使用 Fibonacci 量表估算故事点数
- 对照 INVEST 标准验证
- 按优先级添加到 Backlog 中
- 验证： Story 符合所有 INVEST 标准；Acceptance Criteria 可测试
User Story Template
User Story 模板
As a [persona],
I want to [action/capability],
So that [benefit/value].Example:
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.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.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 |
| 类型 | 模板 | 示例 |
|---|---|---|
| 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 参考
| 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 |
| Persona | 典型需求 | 使用场景 |
|---|---|---|
| End User | 高效、简洁、可靠 | 日常功能使用 |
| Administrator | 可控、可视、安全 | 系统管理 |
| Power User | 自动化、可定制、快捷操作 | 专家级工作流 |
| New User | 引导、学习、安全 | 新用户入门 |
Acceptance Criteria Patterns
Acceptance Criteria 模板
Write testable acceptance criteria using Given-When-Then format.
使用 Given-When-Then 格式编写可测试的 Acceptance Criteria。
Given-When-Then Template
Given-When-Then 模板
Given [precondition/context],
When [action/trigger],
Then [expected outcome].Examples:
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 [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.Acceptance Criteria Checklist
Acceptance Criteria 检查清单
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 |
每个 Story 应包含以下类别的标准：
| 类别 | 示例 |
|---|---|
| 正常流程 | Given 有效输入，When 提交，Then 显示成功消息 |
| 验证规则 | 当必填字段为空时应拒绝输入 |
| 错误处理 | API 失败时必须显示用户友好的提示信息 |
| 性能要求 | 操作应在 2 秒内完成 |
| 可访问性 | 必须仅通过键盘即可导航 |
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 for complete template library.
references/user-story-templates.md| 故事点数 | 最低 Acceptance Criteria 数量 |
|---|---|
| 1-2 | 3-4 条 |
| 3-5 | 4-6 条 |
| 8 | 5-8 条 |
| 13+ | 拆分该故事 |
完整模板库请查看 。
references/user-story-templates.mdEpic Breakdown Workflow
Epic 拆分流程
Break epics into deliverable sprint-sized stories:
- 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
将 Epic 拆分为可在 Sprint 内交付的小型 Story：
- 定义 Epic 的范围和成功标准
- 识别受该 Epic 影响的所有 Persona
- 列出每个 Persona 所需的所有能力
- 将能力分组为逻辑独立的 Story
- 验证每个 Story 的点数 ≤8
- 识别 Story 之间的依赖关系
- 按增量交付顺序排列 Story
- 验证： 每个 Story 都能交付独立价值；所有 Story 覆盖 Epic 的全部范围
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" |
| 技巧 | 使用场景 | 示例 |
|---|---|---|
| 按工作流步骤拆分 | 线性流程 | "Checkout" → "Add to cart" + "Enter payment" + "Confirm order" |
| 按 Persona 拆分 | 多用户类型 | "Dashboard" → "Admin dashboard" + "User dashboard" |
| 按数据类型拆分 | 多输入类型 | "Import" → "Import CSV" + "Import Excel" |
| 按操作类型拆分 | CRUD 功能 | "Manage users" → "Create" + "Edit" + "Delete" |
| 先处理正常流程 | 降低风险 | "Feature" → "Basic flow" + "Error handling" + "Edge cases" |
Epic Example
Epic 示例
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) - EnablerEpic：用户仪表盘
拆分结果：
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) - EnablerSprint Planning Workflow
Sprint 规划流程
Plan sprint capacity and select stories:
- 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
规划 Sprint 容量并选择 Story：
- 计算团队容量（速度 × 可用系数）
- 与利益相关者评审 Sprint 目标
- 从优先级排序后的 Backlog 中选择 Story
- 填充至容量的 80-85%（承诺交付部分）
- 添加延伸目标（额外 10-15%）
- 识别依赖关系和风险
- 将复杂 Story 拆分为任务
- 验证： 承诺点数 ≤ 容量的 85%；所有 Story 均有 Acceptance Criteria
Capacity Calculation
容量计算
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 容量 = 平均速度 × 可用系数
示例：
平均速度：30 点
团队可用率：90%（一名成员部分缺勤）
调整后容量：27 点
承诺交付：23 点（27 的 85%）
延伸目标：4 点（27 的 15%）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，无休假 | 1.0 |
| 一名成员缺勤 50% | 0.9 |
| Sprint 期间有节假日 | 0.8 |
| 多名成员缺勤 | 0.7 |
Sprint Loading Template
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)See for complete planning procedures.
references/sprint-planning-guide.mdSprint 容量: 27 points
Sprint Goal: [清晰、可衡量的目标]
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.mdBacklog Prioritization
Backlog 优先级排序
Prioritize backlog using value and effort assessment.
通过价值与工作量评估对 Backlog 进行优先级排序。
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 |
| 优先级 | 定义 | Sprint 目标 |
|---|---|---|
| 关键 | 阻碍用户使用、涉及安全或数据丢失 | 立即处理 |
| 高 | 核心功能、关键用户需求 | 本次 Sprint |
| 中 | 优化、增强功能 | 未来 2-3 个 Sprint |
| 低 | 锦上添花的功能、小幅优化 | 待办列表 |
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? |
| 因素 | 权重 | 评估问题 |
|---|---|---|
| 业务价值 | 40% | 对收入的影响？用户需求？战略对齐度？ |
| 用户影响 | 30% | 覆盖用户数量？使用频率？ |
| 风险/依赖 | 15% | 技术风险？外部依赖？ |
| 工作量 | 15% | 规模？复杂度？不确定性？ |
INVEST Criteria Validation
INVEST 标准验证
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 |
添加到 Sprint 之前，验证每个 Story：
| 标准 | 验证问题 | 通过条件 |
|---|---|---|
| Independent | 该 Story 是否可以在不依赖其他未承诺 Story 的情况下开发？ | 无阻塞依赖 |
| Negotiable | 实现方式是否灵活？ | 有多种可行方案 |
| Valuable | 是否为用户或业务带来价值？ | "so that" 部分有明确收益 |
| Estimable | 团队是否可以估算其工作量？ | 足够理解以进行规模估算 |
| Small | 是否可以在一个 Sprint 内完成？ | ≤8 故事点数 |
| Testable | 我们是否可以验证其已完成？ | 有清晰的 Acceptance Criteria |
Reference Documentation
参考文档
User Story Templates
User Story 模板
references/user-story-templates.md- 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
references/user-story-templates.md- 按类型划分的标准 Story 格式（feature、improvement、bug fix、enabler）
- Acceptance Criteria 模板（Given-When-Then、Should/Must/Can）
- INVEST 标准验证检查清单
- 故事点数估算指南（Fibonacci 量表）
- 常见 Story 反模式及修复方案
- Story 拆分技巧
Sprint Planning Guide
Sprint 规划指南
references/sprint-planning-guide.md- 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
references/sprint-planning-guide.md- Sprint 规划会议议程
- 容量计算公式
- Backlog 优先级排序框架（WSJF）
- Sprint 仪式指南（站会、评审会、回顾会）
- 速度跟踪与燃尽图模式
- 完成定义（Definition of Done）检查清单
- Sprint 指标与目标
Tools
工具
User Story Generator
User Story 生成器
bash
undefinedbash
undefinedGenerate stories from sample epic
从示例 Epic 生成故事
python scripts/user_story_generator.py
python scripts/user_story_generator.py
Plan sprint with capacity
结合容量规划 Sprint
python scripts/user_story_generator.py sprint 30
Generates:
- INVEST-compliant user stories
- Given-When-Then acceptance criteria
- Story point estimates (Fibonacci scale)
- Priority assignments
- Sprint loading with committed and stretch itemspython scripts/user_story_generator.py sprint 30
生成内容：
- 符合 INVEST 标准的 User Story
- Given-When-Then 格式的 Acceptance Criteria
- 故事点数估算（Fibonacci 量表）
- 优先级分配
- 包含承诺交付和延伸目标的 Sprint 负载Sample Output
示例输出
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
✓ TestableUSER 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
✓ TestableSprint Metrics
Sprint 指标
Track sprint health and team performance.
跟踪 Sprint 健康状况和团队绩效。
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% |
| 指标 | 计算公式 | 目标 |
|---|---|---|
| 速度 | 完成点数 / Sprint | 稳定 ±10% |
| 承诺可靠性 | 完成点数 / 承诺点数 | >85% |
| 范围变更 | Sprint 中期添加或移除的点数 | <10% |
| 遗留工作 | 未完成的点数 | <15% |
Velocity Tracking
速度跟踪
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 pointsSprint 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 pointsDefinition of Done
完成定义（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
Story 完成的条件：
- 代码完成并通过同行评审
- 编写单元测试并通过
- 验证 Acceptance Criteria
- 更新文档
- 部署到预发布环境
- 产品负责人验收通过
- 无严重 bug 遗留