Back to Details

story-definition

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Story Definition

用户故事定义

Help teams define clear, implementable user stories from features, epics, requirements, or ideas. Pull project context from connected tools, apply structured frameworks, and create stories directly in the project tracker.
帮助团队从功能、Epic、需求或想法中定义清晰可落地的用户故事。从关联工具中获取项目背景，应用结构化框架，并直接在项目跟踪工具中创建用户故事。

Workflow

工作流程

Step 1 — Gather context

步骤1 — 收集背景信息

Understand what needs to be broken down before writing anything.
If 
~~project tracker
is connected:
  • Ask the user which project or board to work with
  • Pull the current epics, labels, and team members to understand project structure
  • Check existing backlog for related or duplicate stories
  • Pull any linked requirements, specs, or parent epics for context
  • Identify the project's existing conventions (label taxonomy, story point scale, naming patterns)
If no project tracker is connected:
  • Ask the user to describe the feature, epic, or requirement
  • Ask about the team context: who will implement, what tech stack, any constraints
  • Ask about existing conventions they follow for story format
Always ask:
  • What is the goal or outcome this work should achieve?
  • Are there known constraints (timeline, dependencies, technical limitations)?
  • What level of granularity do they need? (epic-level, sprint-ready, task-level)
在开始撰写前，先明确需要拆分的内容。
若已关联
~~project tracker
：
  • 询问用户要处理哪个项目或看板
  • 获取当前的Epic、标签和团队成员信息，以了解项目结构
  • 检查现有Backlog中是否有相关或重复的用户故事
  • 获取所有关联的需求、规格说明或父级Epic以补充背景信息
  • 明确项目已有的规范（标签分类、故事点估算尺度、命名规则）
若未关联项目跟踪工具：
  • 请用户描述功能、Epic或需求
  • 询问团队背景：谁来实现、使用什么技术栈、有哪些约束条件
  • 询问他们遵循的用户故事格式规范
必问问题：
  • 这项工作要达成的目标或成果是什么？
  • 是否存在已知约束（时间线、依赖关系、技术限制）？
  • 他们需要什么粒度的拆分？（Epic级别、可进入Sprint级别、任务级别）

Step 2 — Analyze and decompose

步骤2 — 分析与拆分

Break down the input into logical, implementable units.
Decomposition principles:
  1. Vertical slicing — Each story delivers a thin slice of end-to-end value, not a horizontal layer. A story should touch all layers needed (UI, API, DB) for one specific behavior.
  2. INVEST criteria — Every story must be:
    • Independent — Can be built and delivered without waiting for other stories (minimize dependencies)
    • Negotiable — Details can be discussed; it is not a rigid specification
    • Valuable — Delivers clear value to a user, stakeholder, or the system
    • Estimable — The team can reasonably estimate the effort
    • Small — Fits within a single sprint (if too big, split further)
    • Testable — Has clear conditions to verify it is done
  3. Dependency mapping — Identify which stories block others and flag circular dependencies
  4. Risk-first ordering — Surface high-risk or high-uncertainty stories early so they can be tackled first
Splitting strategies when a story is too large:
StrategyWhen to useExample
By workflow stepMulti-step process"User can add item to cart" vs "User can checkout"
By business ruleComplex validation"Basic validation" vs "Edge-case handling"
By data variationMultiple entity types"Import CSV contacts" vs "Import CSV companies"
By interfaceMultiple entry points"Create via form" vs "Create via API"
By operationFull CRUD"View list" vs "Edit item" vs "Delete item"
By personaDifferent user types"Admin can configure" vs "Member can view"
Happy path / edge casesComplex flows"Successful payment" vs "Payment retry on failure"
将输入内容拆分为逻辑清晰、可落地的单元。
拆分原则：
  1. 垂直切片 — 每个用户故事交付的是端到端的价值切片，而非横向分层。一个用户故事应覆盖某一特定行为所需的所有层级（UI、API、数据库）。
  2. INVEST准则 — 每个用户故事必须满足：
    • I 独立性 — 无需等待其他用户故事即可开发和交付（尽量减少依赖）
    • N 可协商性 — 细节可讨论，并非刚性规范
    • V 价值性 — 为用户、利益相关者或系统带来明确价值
    • E 可估算性 — 团队可以合理估算工作量
    • S 小型化 — 可在单个Sprint内完成（若过大则进一步拆分）
    • T 可测试性 — 具备明确的完成验证条件
  3. 依赖关系映射 — 识别哪些用户故事会阻塞其他故事，并标记循环依赖
  4. 风险优先排序 — 尽早识别高风险或高不确定性的用户故事，以便优先处理
用户故事过大时的拆分策略：
拆分策略适用场景示例
By workflow step多步骤流程"User can add item to cart" vs "User can checkout"
By business rule复杂验证场景"Basic validation" vs "Edge-case handling"
By data variation多实体类型场景"Import CSV contacts" vs "Import CSV companies"
By interface多入口场景"Create via form" vs "Create via API"
By operation完整CRUD场景"View list" vs "Edit item" vs "Delete item"
By persona不同用户类型场景"Admin can configure" vs "Member can view"
Happy path / edge cases复杂流程场景"Successful payment" vs "Payment retry on failure"

Step 3 — Write stories

步骤3 — 撰写用户故事

Use this format for each story. Adapt field names to match the project's conventions if they differ.
Title: [Action-oriented, concise — starts with a verb or "As a..."]

User story:
As a [specific persona/role],
I want to [concrete action],
so that [measurable outcome or business value].

Acceptance criteria:
- [ ] Given [context], when [action], then [expected result]
- [ ] Given [context], when [action], then [expected result]
- [ ] [Additional criteria using Given/When/Then or plain checkboxes]

Definition of done:
- [ ] Code implemented and passing CI
- [ ] Unit/integration tests covering acceptance criteria
- [ ] Code reviewed and approved
- [ ] [Project-specific DoD items from team conventions]

Technical notes:
- Implementation hints, API contracts, data model changes
- Links to relevant specs, designs, or documentation
- Known risks or open questions to resolve during implementation

Size: [T-shirt (XS/S/M/L/XL) or story points — match project convention]
Priority: [P0-Critical / P1-High / P2-Medium / P3-Low]
Labels: [Use existing project labels when available]
Dependencies: [List story titles or IDs this story depends on]
Writing quality checklist — apply to every story:
  • Title is scannable in a board view (under 80 characters)
  • "So that" clause has a real outcome, not a restatement of the action
  • Acceptance criteria are testable — no ambiguous words like "should work well"
  • Each acceptance criterion covers one behavior (split compound criteria)
  • Technical notes exist for anything non-obvious to the implementer
  • Size reflects actual complexity, not just code volume
  • No hidden work — if the story requires migrations, config changes, or docs updates, they are explicit
每个用户故事都采用以下格式。若项目有不同规范，可调整字段名称以匹配。
Title: [Action-oriented, concise — starts with a verb or "As a..."]

User story:
As a [specific persona/role],
I want to [concrete action],
so that [measurable outcome or business value].

Acceptance criteria:
- [ ] Given [context], when [action], then [expected result]
- [ ] Given [context], when [action], then [expected result]
- [ ] [Additional criteria using Given/When/Then or plain checkboxes]

Definition of done:
- [ ] Code implemented and passing CI
- [ ] Unit/integration tests covering acceptance criteria
- [ ] Code reviewed and approved
- [ ] [Project-specific DoD items from team conventions]

Technical notes:
- Implementation hints, API contracts, data model changes
- Links to relevant specs, designs, or documentation
- Known risks or open questions to resolve during implementation

Size: [T-shirt (XS/S/M/L/XL) or story points — match project convention]
Priority: [P0-Critical / P1-High / P2-Medium / P3-Low]
Labels: [Use existing project labels when available]
Dependencies: [List story titles or IDs this story depends on]
撰写质量检查清单 — 适用于所有用户故事：
  • 标题在看板视图中易于快速阅读（不超过80个字符）
  • “So that”部分需体现实际成果，而非重复动作描述
  • 验收标准可测试 — 避免使用“应正常工作”等模糊表述
  • 每个验收标准对应一项行为（拆分复合标准）
  • 为实现人员可能不清楚的内容添加技术说明
  • 规模估算反映实际复杂度，而非仅代码量
  • 无隐藏工作 — 若用户故事涉及数据迁移、配置变更或文档更新，需明确列出

Step 4 — Validate and organize

步骤4 — 验证与整理

Before presenting or creating stories, run a quality pass.
Validation checks:
  1. Coverage — Does the full set of stories deliver the complete feature/epic? Identify gaps.
  2. Overlap — Are any two stories doing the same work? Merge or clarify boundaries.
  3. Dependency graph — Can the stories be ordered into a buildable sequence? Flag circular dependencies.
  4. Sprint fitness — Is each story small enough for one sprint? Flag any that need further splitting.
  5. Testability — Can QA verify every acceptance criterion without ambiguity?
  6. Backlog check — If 
    ~~project tracker
    is connected, verify no existing stories already cover this work.
Organize the output:
  • Group stories by epic or functional area
  • Order by suggested implementation sequence (dependencies first, then priority)
  • Clearly mark which stories are sprint-ready vs need further refinement
  • Summarize the total scope: number of stories, estimated total effort, suggested sprint distribution
在展示或创建用户故事前，进行质量检查。
验证检查项：
  1. 覆盖度 — 所有用户故事是否能完整交付该功能/Epic？识别遗漏点。
  2. 重叠度 — 是否有两个用户故事的工作内容重复？合并或明确边界。
  3. 依赖关系图 — 用户故事能否排序为可构建的序列？标记循环依赖。
  4. Sprint适配性 — 每个用户故事是否小到可在单个Sprint内完成？标记需要进一步拆分的故事。
  5. 可测试性 — QA能否无歧义地验证所有验收标准？
  6. 待办事项检查 — 若已关联
    ~~project tracker
    ，验证是否已有现有用户故事覆盖该工作内容。
整理输出内容：
  • 按Epic或功能领域对用户故事进行分组
  • 按建议的实现顺序排序（先依赖项，后优先级）
  • 明确标记哪些用户故事已就绪可进入Sprint，哪些需要进一步优化
  • 总结总范围：用户故事数量、估算总工作量、建议的Sprint分配方案

Step 5 — Create in project tracker

步骤5 — 在项目跟踪工具中创建

If 
~~project tracker
is connected:
  • Confirm with the user before creating any tickets
  • Show a summary table first:
#TitleSizePriorityDependencies
1...SP1—
2...MP1#1
  • After user approval, create each story in the connected tool
  • Apply labels, assignees, sprint, and parent epic as discussed
  • Set up dependency links between stories where supported
  • Report back with links to created tickets
If no project tracker is connected:
  • Present the stories in the structured format above
  • Offer to export as markdown or a formatted list the user can paste into their tool
若已关联
~~project tracker
：
  • 创建任何工单前需与用户确认
  • 先展示汇总表格：
#TitleSizePriorityDependencies
1...SP1—
2...MP1#1
  • 获得用户批准后，在关联工具中创建每个用户故事
  • 按讨论结果添加标签、经办人、Sprint和父级Epic
  • 在支持的工具中设置用户故事间的依赖链接
  • 返回已创建工单的链接
若未关联项目跟踪工具：
  • 以上述结构化格式展示用户故事
  • 提供导出为markdown或格式化列表的选项，方便用户粘贴到自己的工具中

Step 6 — Notify team

步骤6 — 通知团队

If 
~~chat
is connected:
  • Ask if the user wants to notify the team about the new stories
  • Draft a concise message summarizing what was created, how many stories, total estimated effort, and a link to the board/project
  • Post only after user confirms
若已关联
~~chat
工具：
  • 询问用户是否要通知团队有关新用户故事的信息
  • 撰写简洁的消息，总结创建的内容、用户故事数量、估算总工作量以及看板/项目的链接
  • 仅在用户确认后发送消息

Story sizing guide

用户故事规模估算指南

Use the project's existing scale. If none exists, suggest one of these:
T-shirt sizes (recommended for teams new to estimation):
SizeTypical scopeExamples
XSConfig change, copy update, one-line fixToggle a feature flag, fix a typo
SSingle component, clear pathAdd a form field, new API endpoint with known pattern
MMultiple components, some unknownsNew CRUD feature, integration with documented API
LCross-cutting, needs design decisionsNew auth flow, data migration with transformation
XLShould probably be split furtherFull feature redesign, new service
Fibonacci story points (for teams using velocity tracking):
PointsRelative effort
1Trivial — hours
2Small — a day or less
3Moderate — a couple of days
5Significant — most of a week
8Large — full week, consider splitting
13Very large — must split
使用项目已有的估算尺度。若没有，可建议以下其中一种：
T恤尺码法（推荐给估算经验不足的团队）：
Size典型范围Examples
XS配置变更、文案更新、单行代码修复Toggle a feature flag, fix a typo
S单个组件、实现路径清晰Add a form field, new API endpoint with known pattern
M多个组件、存在部分未知项New CRUD feature, integration with documented API
L跨模块、需要设计决策New auth flow, data migration with transformation
XL需进一步拆分Full feature redesign, new service
斐波那契故事点法（适用于使用速度跟踪的团队）：
Points相对工作量
1极小 — 数小时
2小 — 1天或更短
3中等 — 数天
5较大 — 一周的大部分时间
8大 — 整周，考虑拆分
13极大 — 必须拆分

Priority framework

优先级框架

LevelLabelCriteriaAction
P0CriticalBlocks release, security issue, data loss riskImmediate — current sprint
P1HighCore to the feature/epic goal, high user impactNext available sprint
P2MediumValuable improvement, not blockingBacklog — schedule when capacity allows
P3LowNice-to-have, polish, minor enhancementBacklog — revisit during planning
LevelLabel判定标准处理方式
P0Critical阻塞发布、安全问题、数据丢失风险立即处理 — 当前Sprint
P1High功能/Epic目标核心、用户影响大下一个可用Sprint处理
P2Medium有价值的改进、不阻塞进度放入Backlog — 有容量时安排
P3Low锦上添花的功能、优化、小增强放入Backlog — 规划时再回顾

Anti-patterns to avoid

需避免的反模式

Anti-patternProblemFix
"Implement feature X"No user value stated, no acceptance criteriaAdd persona, outcome, and testable criteria
Horizontal slicing"Build the API" then "Build the UI" — no deliverable value until both doneSlice vertically — one behavior end-to-end
Giant stories"As a user I want the whole checkout flow" — unestimableSplit by workflow step, operation, or business rule
Vague acceptance criteria"It should work correctly" — untestableUse Given/When/Then with specific inputs and outputs
Missing dependenciesStory fails because a prerequisite was not identifiedMap dependencies explicitly during decomposition
Gold-platingStory includes "nice-to-have" details mixed with core requirementsSeparate must-have criteria from enhancements
Copy-paste personas"As a user" for everything — loses contextUse specific roles: admin, member, guest, API consumer
反模式问题解决方法
"Implement feature X"未说明用户价值、无验收标准添加用户角色、成果和可测试标准
Horizontal slicing"先构建API再构建UI" — 两者完成前无交付价值采用垂直切片 — 单个行为端到端实现
Giant stories"As a user I want the whole checkout flow" — 无法估算按工作流步骤、操作类型或业务规则拆分
Vague acceptance criteria"It should work correctly" — 不可测试使用Given/When/Then格式，明确输入和输出
Missing dependencies因未识别前置条件导致用户故事失败拆分阶段明确映射依赖关系
Gold-plating用户故事中混入"锦上添花"的细节与核心需求将必备标准与增强功能分离
Copy-paste personas所有故事都用"作为用户" — 丢失上下文使用具体角色：管理员、成员、访客、API消费者