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:

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.
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
Dependency mapping — Identify which stories block others and flag circular dependencies
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:

Strategy	When to use	Example
By workflow step	Multi-step process	"User can add item to cart" vs "User can checkout"
By business rule	Complex validation	"Basic validation" vs "Edge-case handling"
By data variation	Multiple entity types	"Import CSV contacts" vs "Import CSV companies"
By interface	Multiple entry points	"Create via form" vs "Create via API"
By operation	Full CRUD	"View list" vs "Edit item" vs "Delete item"
By persona	Different user types	"Admin can configure" vs "Member can view"
Happy path / edge cases	Complex flows	"Successful payment" vs "Payment retry on failure"

将输入内容拆分为逻辑清晰、可落地的单元。

拆分原则：

垂直切片 — 每个用户故事交付的是端到端的价值切片，而非横向分层。一个用户故事应覆盖某一特定行为所需的所有层级（UI、API、数据库）。
INVEST准则 — 每个用户故事必须满足：
- I 独立性 — 无需等待其他用户故事即可开发和交付（尽量减少依赖）
- N 可协商性 — 细节可讨论，并非刚性规范
- V 价值性 — 为用户、利益相关者或系统带来明确价值
- E 可估算性 — 团队可以合理估算工作量
- S 小型化 — 可在单个Sprint内完成（若过大则进一步拆分）
- T 可测试性 — 具备明确的完成验证条件
依赖关系映射 — 识别哪些用户故事会阻塞其他故事，并标记循环依赖
风险优先排序 — 尽早识别高风险或高不确定性的用户故事，以便优先处理

用户故事过大时的拆分策略：

拆分策略	适用场景	示例
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:

Coverage — Does the full set of stories deliver the complete feature/epic? Identify gaps.
Overlap — Are any two stories doing the same work? Merge or clarify boundaries.
Dependency graph — Can the stories be ordered into a buildable sequence? Flag circular dependencies.
Sprint fitness — Is each story small enough for one sprint? Flag any that need further splitting.
Testability — Can QA verify every acceptance criterion without ambiguity?
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

在展示或创建用户故事前，进行质量检查。

验证检查项：

覆盖度 — 所有用户故事是否能完整交付该功能/Epic？识别遗漏点。
重叠度 — 是否有两个用户故事的工作内容重复？合并或明确边界。
依赖关系图 — 用户故事能否排序为可构建的序列？标记循环依赖。
Sprint适配性 — 每个用户故事是否小到可在单个Sprint内完成？标记需要进一步拆分的故事。
可测试性 — QA能否无歧义地验证所有验收标准？
待办事项检查 — 若已关联
```
~~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:

#	Title	Size	Priority	Dependencies
1	...	S	P1	—
2	...	M	P1	#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
：

创建任何工单前需与用户确认
先展示汇总表格：

#	Title	Size	Priority	Dependencies
1	...	S	P1	—
2	...	M	P1	#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):

Size	Typical scope	Examples
XS	Config change, copy update, one-line fix	Toggle a feature flag, fix a typo
S	Single component, clear path	Add a form field, new API endpoint with known pattern
M	Multiple components, some unknowns	New CRUD feature, integration with documented API
L	Cross-cutting, needs design decisions	New auth flow, data migration with transformation
XL	Should probably be split further	Full feature redesign, new service

Fibonacci story points (for teams using velocity tracking):

Points	Relative effort
1	Trivial — hours
2	Small — a day or less
3	Moderate — a couple of days
5	Significant — most of a week
8	Large — full week, consider splitting
13	Very 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

优先级框架

Level	Label	Criteria	Action
P0	Critical	Blocks release, security issue, data loss risk	Immediate — current sprint
P1	High	Core to the feature/epic goal, high user impact	Next available sprint
P2	Medium	Valuable improvement, not blocking	Backlog — schedule when capacity allows
P3	Low	Nice-to-have, polish, minor enhancement	Backlog — revisit during planning

Level	Label	判定标准	处理方式
P0	Critical	阻塞发布、安全问题、数据丢失风险	立即处理 — 当前Sprint
P1	High	功能/Epic目标核心、用户影响大	下一个可用Sprint处理
P2	Medium	有价值的改进、不阻塞进度	放入Backlog — 有容量时安排
P3	Low	锦上添花的功能、优化、小增强	放入Backlog — 规划时再回顾

Anti-patterns to avoid

需避免的反模式

Anti-pattern	Problem	Fix
"Implement feature X"	No user value stated, no acceptance criteria	Add persona, outcome, and testable criteria
Horizontal slicing	"Build the API" then "Build the UI" — no deliverable value until both done	Slice vertically — one behavior end-to-end
Giant stories	"As a user I want the whole checkout flow" — unestimable	Split by workflow step, operation, or business rule
Vague acceptance criteria	"It should work correctly" — untestable	Use Given/When/Then with specific inputs and outputs
Missing dependencies	Story fails because a prerequisite was not identified	Map dependencies explicitly during decomposition
Gold-plating	Story includes "nice-to-have" details mixed with core requirements	Separate must-have criteria from enhancements
Copy-paste personas	"As a user" for everything — loses context	Use 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消费者