User Story Writing

用户故事撰写技能

目的

编写清晰且有价值的用户故事，传达敏捷／混合环境中的需求，并为开发团队提供指导。

适用场景

• 敏捷或混合项目
• Sprint 规划和待办事项梳理
• 将功能拆分为可实现的部分
• 向开发团队传达需求

用户故事格式

基本模板

As a [user role]
I want [goal/desire]
So that [benefit/value]

增强模板（推荐）

Title: [Short, descriptive title]

As a [user role]
I want [goal/desire]
So that [benefit/value]

Acceptance Criteria:
- [Criterion 1]
- [Criterion 2]
- [Criterion 3]

Notes:
[Additional context, wireframes, business rules]

Definition of Done:
- [ ] Code complete and peer reviewed
- [ ] Unit tests written and passing
- [ ] Integration tests passing
- [ ] Acceptance criteria met
- [ ] Documentation updated

INVEST 标准

每个用户故事都应符合以下标准：

• Independent（独立）：可以独立开发和交付
• Negotiable（可协商）：细节可以讨论和完善
• Valuable（有价值）：为用户或业务创造价值
• Estimable（可估算）：团队可以估算所需工作量
• Small（小型）：可以在一个 Sprint 内完成
• Testable（可测试）：具有明确的验收标准，便于测试

各领域示例

电子商务示例

故事 1：访客结账

Title: Guest Checkout Without Account Creation

As a first-time customer
I want to complete my purchase without creating an account
So that I can checkout quickly without friction

Acceptance Criteria:
- Given I have items in my cart
  When I click "Checkout as Guest"
  Then I can enter shipping and payment info without login
- Given I complete guest checkout
  When I receive order confirmation
  Then I see an option to create an account
- Given my order total is over $5000
  When I try to checkout as guest
  Then I am required to create an account for security

Business Rules:
- Guest checkout not available for orders > $5000
- Email required for order confirmation
- Guest orders linked to email for future reference

Story Points: 8
Priority: Must Have
Sprint: Sprint 3

故事 2：实时运费计算

Title: Real-time Shipping Cost Display

As a customer
I want to see shipping costs before entering payment information
So that I know the total cost upfront and avoid surprises

Acceptance Criteria:
- Given I enter a valid shipping address
  When I proceed to shipping method selection
  Then I see all available shipping options with costs
- Given I select a shipping method
  When I view the order summary
  Then the shipping cost is included in the total
- Given the shipping API is unavailable
  When I try to calculate shipping
  Then I see a fallback message with estimated costs

Technical Notes:
- Integrate with ShipStation API
- Cache shipping rates for 5 minutes
- Timeout after 5 seconds, show fallback

Story Points: 5
Priority: Must Have
Sprint: Sprint 3

CRM 示例

故事 3：自动潜在客户评分

Title: Automatic Lead Scoring Based on Behavior

As a sales manager
I want leads to be automatically scored based on their activities
So that my team focuses on the most qualified prospects

Acceptance Criteria:
- Given a lead visits the pricing page
  When the activity is tracked
  Then 15 points are added to their score
- Given a lead's score reaches 60
  When the score is updated
  Then the lead is automatically marked as MQL
- Given a lead's score reaches 75
  When the score is updated
  Then the lead is assigned to a sales rep and rep is notified
- Given I view a lead record
  When I look at the lead score
  Then I can see the scoring breakdown (why this score)

Scoring Rules:
- Demographic: Job title (0-20), Company size (0-15), Industry (0-5)
- Behavioral: Pricing page (15), Whitepaper (10), Webinar (15), Demo request (25)

Story Points: 13
Priority: Must Have
Sprint: Sprint 5

移动端／Web 示例

故事 4：离线查看订单

Title: View Orders Offline in Mobile App

As a mobile app user
I want to view my order history when offline
So that I can check order details without internet connection

Acceptance Criteria:
- Given I have previously viewed orders while online
  When I open the app offline
  Then I can see my cached order history
- Given I am offline
  When I try to view order details
  Then I see the last synced information with "offline" indicator
- Given I regain internet connection
  When the app detects connectivity
  Then order data is automatically refreshed in background

Technical Notes:
- Cache last 50 orders in local storage
- Use SQLite for offline storage
- Sync on app foreground if connected

Story Points: 8
Priority: Should Have
Sprint: Sprint 7

ERP 示例

故事 5：多级采购审批

Title: Multi-level Purchase Order Approval Workflow

As a procurement manager
I want purchase orders to route through appropriate approval levels
So that spending is controlled according to company policy

Acceptance Criteria:
- Given a PO is created for $1K-$10K
  When the PO is submitted
  Then it routes to department manager for approval
- Given a PO is created for $10K-$50K
  When the PO is submitted
  Then it routes to department manager, then finance director
- Given a PO is created for >$50K
  When the PO is submitted
  Then it routes to department manager, finance director, then CFO
- Given an approver is out of office
  When a PO requires their approval
  Then it automatically routes to their designated backup
- Given an approver rejects a PO
  When the rejection is submitted
  Then the requester is notified with rejection reason

Approval Matrix:
- $0-$1K: Auto-approved
- $1K-$10K: Department Manager
- $10K-$50K: Department Manager → Finance Director
- >$50K: Department Manager → Finance Director → CFO

Story Points: 13
Priority: Must Have
Sprint: Sprint 4

CDP 示例

故事 6：客户身份解析

Title: Unify Customer Profiles Across Channels

As a marketing analyst
I want customer data from web, mobile, and CRM to be unified
So that I have a complete view of each customer

Acceptance Criteria:
- Given a customer logs in on web and mobile with same email
  When identity resolution runs
  Then both profiles are merged into single customer record
- Given a customer has multiple emails
  When I manually link the profiles
  Then all activities are consolidated under primary profile
- Given profiles are merged
  When I view the customer record
  Then I see all touchpoints across channels in timeline
- Given a merge conflict occurs (different names, addresses)
  When the system detects conflict
  Then it flags for manual review

Matching Rules:
- Email (exact match) - High confidence
- Phone + Name (fuzzy match) - Medium confidence
- Cookie ID + Email domain - Low confidence

Story Points: 21
Priority: Must Have
Sprint: Sprint 2-3 (2 sprints)

故事层级

Epic → 功能 → 用户故事 → 任务

Epic：大型工作项（多个 Sprint）

Epic: Mobile App Customer Self-Service
Goal: Enable customers to manage accounts via mobile app
Timeline: Q1 2026
Stories: 25-30 stories

功能：一组相关故事（1–3 个 Sprint）

Feature: Order Management in Mobile App
Stories: View orders, Track shipments, Initiate returns
Sprint: Sprint 5-6

用户故事：一项独立功能（1 个 Sprint）

Story: View Order History
Tasks: API integration, UI development, Offline caching
Sprint: Sprint 5

任务：技术实现步骤（数小时／数天）

Task: Implement order list API endpoint
Estimate: 4 hours

验收标准格式

Given-When-Then（Gherkin）

Given [context/precondition]
When [action/event]
Then [expected outcome]

示例：

Given I am a logged-in customer
When I click "View Orders"
Then I see a list of my orders sorted by date (newest first)

检查清单格式

- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

示例：

- [ ] Order list displays order number, date, total, status
- [ ] Orders are paginated (20 per page)
- [ ] User can filter by status (All, Processing, Shipped, Delivered)
- [ ] User can search by order number
- [ ] Clicking an order opens order details

基于场景的格式

Scenario 1: [Happy path]
Scenario 2: [Alternative path]
Scenario 3: [Error case]

用户故事拆分技巧

当故事过大（>13 点数）时，可按以下方式拆分：

1. 工作流步骤

• 原始故事：“用户可以完成结账”
• 拆分为：“输入配送信息”、“选择配送方式”、“输入付款信息”、“查看订单”

2. 业务规则

• 原始故事：“计算运费”
• 拆分为：“标准配送”、“快递配送”、“国际配送”

3. CRUD 操作

• 原始故事：“管理产品”
• 拆分为：“创建产品”、“更新产品”、“删除产品”、“查看产品”

4. 数据变体

• 原始故事：“导入客户数据”
• 拆分为：“从 CSV 导入”、“从 Excel 导入”、“从 API 导入”

5. 平台

• 原始故事：“移动应用结账”
• 拆分为：“iOS 结账”、“Android 结账”

6. 简单／复杂程度

• 原始故事：“搜索产品”
• 拆分为：“基本关键词搜索”、“高级筛选”、“分面搜索”

故事估算

故事点数（斐波那契数列：1、2、3、5、8、13、21）

• 1 点：微小改动（数小时）
• 2 点：简单功能（半天）
• 3 点：直接明了的功能（1 天）
• 5 点：中等复杂度（2–3 天）
• 8 点：复杂功能（3–5 天）
• 13 点：非常复杂（5–8 天）——考虑拆分
• 21 点及以上：过大——必须拆分

T 恤尺码（替代方案）

• XS：1–2 点
• S：3–5 点
• M：8 点
• L：13 点
• XL：21 点及以上（必须拆分）

就绪定义（DoR）

故事满足以下条件后，即可进入 Sprint：

• 用户故事符合 INVEST 标准
• 验收标准清晰且可测试
• 已识别并解决依赖项
• 已提供线框图／模型图（如涉及 UI 工作）
• 已记录业务规则
• 团队已估算故事
• 已分配优先级
• 已讨论技术方案

完成定义（DoD）

故事满足以下条件后，即视为完成：

• 代码已完成并经过同行评审
• 已编写单元测试（覆盖率 >80%）
• 集成测试已通过
• 已满足所有验收标准
• 已完成手动测试
• 文档已更新
• 已部署到预发布环境
• 产品负责人已批准

最佳实践

✅ 应该：

• 从用户视角出发
• 关注价值，而非实现方式
• 保持用户故事简短、聚焦
• 包含明确的验收标准
• 让团队参与编写用户故事
• 在冲刺规划前完善用户故事
• 将用户故事关联到史诗和功能

❌ 不应该：

• 将技术任务写成用户故事
• 让用户故事过于庞大（>13 点）
• 跳过验收标准
• 编写含糊不清或模棱两可的用户故事
• 包含实现细节
• 在同一冲刺中的用户故事之间创建依赖关系

工具

Lark

• 使用 Lark Base 管理待办事项
• 创建带有自定义字段的用户故事模板
• 将用户故事关联到史诗和冲刺
• 跟踪用户故事的状态和进度

Notion

• 创建用户故事数据库
• 使用看板进行冲刺规划
• 将用户故事关联到需求和测试用例
• 使用模板确保用户故事格式一致

常见模式

电子商务

• 作为客户，我想要 [购物/结账功能]
• 作为管理员，我想要 [产品/订单管理]
• 作为商家，我想要 [分析/报告]

CRM

• 作为销售代表，我想要 [潜在客户/商机管理]
• 作为经理，我想要 [销售管道/预测]
• 作为营销人员，我想要 [营销活动/自动化]

ERP

• 作为用户，我想要 [流程自动化]
• 作为审批人，我想要 [工作流管理]
• 作为管理员，我想要 [配置/设置]

移动端/网页

• 作为移动端用户，我想要 [随时随地使用的功能]
• 作为用户，我想要 [响应式/无障碍 UI]
• 作为用户，我想要 [离线功能]

后续步骤

编写用户故事后：

1. 在待办事项梳理期间与团队一起完善
2. 制定验收标准（参见 acceptance-criteria skill）
3. 在计划扑克中进行估算
4. 拆分为技术任务
5. 关联到 UAT 测试用例

参考资料

• Mike Cohn - 《User Stories Applied》
• INVEST 标准 - Bill Wake
• Agile Alliance - 用户故事指南
• Scrum Guide - 产品待办事项管理