agile-story-generation

敏捷故事生成

概述

此技能可在 ServiceNow 的 Agile Development 2.0 模块中，根据高层需求、功能描述或利益相关方的请求生成结构良好的用户故事。涵盖以下内容：

• 将功能拆解为大小合适的用户故事
• 按标准的“作为……／我想要……／以便……”格式编写故事
• 使用相对估算法估算故事点数
• 将故事关联到史诗并分配到冲刺
• 为每个故事生成验收标准
• 设置优先级和分类字段

使用场景： 产品负责人、Scrum Master 或业务分析师需要在 ServiceNow SPM 中将需求转化为可纳入待办列表的用户故事时。

先决条件

• 插件： com.snc.sdlc.agile.2.0（Agile Development 2.0）
• 角色： scrum_user、scrum_master 或 scrum_admin
• 访问权限： 对 rm_story、rm_epic、rm_sprint 表具有读写权限
• 知识： 了解项目的史诗、冲刺节奏和团队速率

操作步骤

步骤 1：确定目标史诗和冲刺

查询项目中的现有史诗，确定新故事应归属的位置。

使用 MCP（Claude Code/Desktop）：

Tool: SN-Query-Table
Parameters:
  table_name: rm_epic
  query: product.sys_id=[product_sys_id]^state!=3
  fields: sys_id,number,short_description,state,priority,story_points_total
  limit: 20

使用 REST API：

GET /api/now/table/rm_epic?sysparm_query=product.sys_id=[product_sys_id]^state!=3&sysparm_fields=sys_id,number,short_description,state,priority,story_points_total&sysparm_limit=20

查询当前进行中的冲刺，找到要分配的目标冲刺：

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: rm_sprint
  query: release.product.sys_id=[product_sys_id]^state=2
  fields: sys_id,number,short_description,start_date,end_date,story_points,capacity
  limit: 5

使用 REST API：

GET /api/now/table/rm_sprint?sysparm_query=release.product.sys_id=[product_sys_id]^state=2&sysparm_fields=sys_id,number,short_description,start_date,end_date,story_points,capacity&sysparm_limit=5

步骤 2：分析需求

将功能描述拆解为可独立交付的用户故事。应用 INVEST 标准：

标准	描述	验证方式
Independent（独立）	不依赖其他故事	可单独开发
Negotiable（可协商）	细节可以讨论	未过度具体化
Valuable（有价值）	为用户／业务带来价值	有明确的“以便”子句
Estimable（可估算）	团队可以估算大小	范围清晰明了
Small（小型）	可在单个冲刺内完成	通常为 1-8 个故事点
Testable（可测试）	通过／未通过标准明确	包含验收标准

步骤 3：生成用户故事

为每个已确定的故事在 rm_story 表中创建记录。

使用 MCP：

Tool: SN-Create-Record
Parameters:
  table_name: rm_story
  fields:
    short_description: "As a [persona], I want to [action] so that [benefit]"
    description: |
      ## User Story
      **As a** customer service representative
      **I want to** search for customers by phone number
      **So that** I can quickly locate their account during inbound calls

      ## Details
      - Search should support partial phone number matching
      - Results should display customer name, account number, and status
      - Search should return results within 2 seconds

      ## Technical Notes
      - Leverage existing customer API endpoint
      - Index phone_number field for performance
    story_points: 5
    epic: [epic_sys_id]
    sprint: [sprint_sys_id]
    state: -6
    priority: 2
    acceptance_criteria: |
      Given I am logged in as a service representative
      When I enter a phone number (full or partial) in the search field
      Then matching customer records are displayed within 2 seconds

      Given no matching records exist
      When I search for a phone number
      Then a "No results found" message is displayed

      Given multiple matches are found
      When results are displayed
      Then they are sorted by relevance with exact matches first
    product: [product_sys_id]
    assigned_to: [user_sys_id]
    classification: Enhancement

使用 REST API：

POST /api/now/table/rm_story
Content-Type: application/json

{
  "short_description": "As a customer service rep, I want to search customers by phone number so I can locate accounts quickly",
  "description": "## User Story\n**As a** customer service representative\n**I want to** search for customers by phone number\n**So that** I can quickly locate their account during inbound calls",
  "story_points": 5,
  "epic": "[epic_sys_id]",
  "sprint": "[sprint_sys_id]",
  "state": "-6",
  "priority": 2,
  "acceptance_criteria": "Given I am logged in as a service representative\nWhen I enter a phone number in the search field\nThen matching customer records are displayed within 2 seconds",
  "product": "[product_sys_id]",
  "classification": "Enhancement"
}

步骤 4：估算故事点数

根据团队速率和复杂度进行相对估算。使用改良的斐波那契数列：

点数	工作量级别	示例
1	微小	文本更改、配置更新
2	简单	添加单个字段并进行验证
3	较小	带有基本逻辑的新 UI 组件
5	中等	包含多个集成点的功能
8	较大	跨多个模块的复杂功能
13	非常大	考虑拆分为更小的故事

估算完成后更新故事点数：

使用 MCP：

Tool: SN-Update-Record
Parameters:
  table_name: rm_story
  sys_id: [story_sys_id]
  fields:
    story_points: 5
    blocked: false

使用 REST API：

PATCH /api/now/table/rm_story/[story_sys_id]
Content-Type: application/json

{
  "story_points": 5,
  "blocked": false
}

步骤 5：验证冲刺容量

分配故事前，确认冲刺仍有可用容量。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: rm_sprint
  query: sys_id=[sprint_sys_id]
  fields: sys_id,short_description,capacity,story_points,start_date,end_date
  limit: 1

计算剩余容量：remaining = capacity - story_points。只有当新故事的故事点数总和不超过剩余容量时，才分配这些故事。

步骤 6：关联故事到史诗并进行验证

查询史诗，确认所有故事均已正确关联：

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: rm_story
  query: epic=[epic_sys_id]^ORDERBYpriority
  fields: number,short_description,story_points,state,sprint,assigned_to,priority
  limit: 50

使用 REST API：

GET /api/now/table/rm_story?sysparm_query=epic=[epic_sys_id]^ORDERBYpriority&sysparm_fields=number,short_description,story_points,state,sprint,assigned_to,priority&sysparm_limit=50

工具用法

MCP 工具参考

工具	使用场景
SN-Query-Table	查询史诗、冲刺、现有故事和产品
SN-Create-Record	在 rm_story 中创建新的用户故事
SN-Update-Record	更新故事点数、分配情况和状态
SN-Natural-Language-Search	使用自然语言搜索相关故事或需求

REST API 参考

Endpoint	Method	Purpose
/api/now/table/rm_story	GET	查询现有故事
/api/now/table/rm_story	POST	创建新故事
/api/now/table/rm_story/{sys_id}	PATCH	更新故事字段
/api/now/table/rm_epic	GET	查询 Epic 以进行关联
/api/now/table/rm_sprint	GET	查询 Sprint 以进行分配

最佳实践

• 每个故事对应一个操作： 每个故事应描述单一用户操作或能力
• 包含验收标准： 每个故事在 Sprint 规划前都必须有可测试的验收标准
• 合理控制故事规模： 目标为 1-8 个故事点；预估为 13 个及以上的故事应拆分
• 使用用户角色： 从实际用户角色的角度编写故事，而非泛泛地使用“用户”
• 避免技术术语： 故事描述做什么，而非如何做；将实现细节保留在任务中
• 关联 Epic： 始终将故事关联到其父级 Epic，以便追踪
• 核实容量： 分配故事前检查 Sprint 容量，避免超额承诺
• 设置分类： 使用 Enhancement、Defect 或 Spike 对故事类型进行分类

故障排除

关联故事时出现“Epic not found”

原因： Epic sys_id 不正确，或 Epic 属于其他产品
解决方案： 使用产品筛选条件查询 rm_epic，以查找有效 Epic：product=[product_sys_id]^state!=3

出现“Sprint capacity exceeded”警告

原因： 添加的故事超出了 Sprint 配置的容量
解决方案： 检查 Sprint 记录中的 capacity 与 story_points；考虑将故事移至下一个 Sprint

“Story not appearing on sprint board”

原因： 故事未分配 Sprint，或处于 Draft 状态
解决方案： 确认已设置 sprint 字段，且状态至少为“Ready”（state=-5）

“Cannot assign story to closed sprint”

原因： Sprint 状态为 Complete（3）或 Closed
解决方案： 使用 state=2 查询正在进行的 Sprint，并将故事分配到当前或未来的 Sprint

示例

示例 1：电子商务功能拆解

输入需求：“用户应能够管理购物车”

生成的故事：

1. STY0010001 - “作为购物者，我希望将商品添加到购物车，以便稍后购买”（3 个故事点）
2. STY0010002 - “作为购物者，我希望从购物车中移除商品，以便改变主意”（2 个故事点）
3. STY0010003 - “作为购物者，我希望更新购物车中的商品数量，以便购买多件商品”（3 个故事点）
4. STY0010004 - “作为购物者，我希望查看包含小计的购物车摘要，以便了解消费金额”（5 个故事点）
5. STY0010005 - “作为购物者，我希望购物车内容在不同会话之间保留，以免丢失所选商品”（5 个故事点）

**合计：**5 个故事共 18 个故事点

示例 2：包含完整详情的单个故事

输入：“需要为移动应用实现密码重置功能”

Tool: SN-Create-Record
Parameters:
  table_name: rm_story
  fields:
    short_description: "As a mobile app user, I want to reset my password from the login screen so that I can regain access to my account"
    story_points: 5
    epic: [auth_epic_sys_id]
    sprint: [current_sprint_sys_id]
    priority: 2
    state: -6
    classification: Enhancement
    acceptance_criteria: |
      Given I am on the mobile login screen
      When I tap "Forgot Password"
      Then I am prompted to enter my registered email address

      Given I enter a valid registered email
      When I submit the reset request
      Then I receive a password reset link via email within 60 seconds

      Given I click the reset link from the email
      When I enter a new password meeting complexity requirements
      Then my password is updated and I can log in with the new credentials

      Given I enter an unregistered email
      When I submit the reset request
      Then I see a generic message (no indication whether email exists)

相关技能

• spm/acceptance-criteria - 详细生成验收标准
• spm/project-insights - 跟踪项目健康状况和速度
• spm/planning-summarization - 总结 Sprint 和发布规划
• spm/feedback-summarization - 分析回顾反馈
• development/automated-testing - 根据故事生成测试用例