制定用户故事编写规范，核心是把“好故事”的判断标准落成一份团队可执行的文档：先划定适用范围，再定义故事结构与字段，规定拆分粒度、优先级和状态流转，明确产品经理、开发、测试的分工，最后配一份检查清单和示例库，并在两三个迭代中试用后修订。本文按这个顺序给出可直接套用的框架，覆盖规范应包含的内容、字段模板、角色职责与发布前自查，不涉及需求内容的业务判断与澄清方法。
要点总览（TL;DR）
- 制定用户故事编写规范的核心，是把“好故事”的判断标准落成一份可执行文档：先划定适用范围，再定义字段与模板，规定粒度、优先级和状态流转，明确角色分工，最后配检查清单与示例库。
- 字段定义表是规范主体，建议采用“作为—我希望—以便”的故事句式与“给定—当—则”的验收条件写法，并区分必填与选填，必填项缺失时故事不进入评审。
- 粒度以“一个迭代内由一名开发完成、验收条件可一次评审确认、能独立产生可观察价值”为判断依据；优先级要写等级并注明依据来源，状态流转每个节点设准入条件。
- 规范先在两到三个迭代内试点，记录填写耗时与评审退回原因，再集中修订一次；指定一名负责人按季度检查，需求流程或团队角色变化时随时更新。
- 规范文档、字段模板与示例库可放在同一文档空间维护，ONES Wiki 的模板库、页面组关联项目与版本回滚能力可用于承载，具体权限与版本能力以实际产品版本为准。
规范先定边界：覆盖哪些需求、适用哪些团队
规范最容易失控的地方，是试图管住所有需求。制定第一步应当写清“管什么、不管什么、谁来用”，让后续字段和流程有明确的服务对象。边界不清时，团队会把技术重构、内部工具、运营配置都套进用户故事模板，结果模板越写越长，评审却越来越难判断。
一份可用的适用范围说明，建议包含三部分内容：覆盖的需求类型、排除的需求类型、适用团队与角色。覆盖范围通常以面向最终用户或外部客户的功能需求为主，这类需求有明确的角色、目标和价值，适合用用户故事表达。排除范围可以列出技术重构、基础设施升级、内部效率工具等，并说明它们改用哪种需求描述方式，例如技术任务说明或缺陷单。排除不等于不管理，而是换一种更合适的表达载体。
适用团队需要写清角色范围：产品经理负责编写，开发与测试参与评审，设计在涉及交互的需求中提供输入。如果团队有多个产品线，还要说明规范是统一执行还是按产品线细化，避免出现同一份文档在不同团队理解不一致。
规范与既有需求流程文档的关系也要交代。用户故事规范通常作为需求管理流程的附件或子文档，承接流程中“需求提出—评审—排期”的环节，不重复定义需求审批权限和排期规则。可以在文档开头用一段话说明：本规范规定需求如何表达，需求是否立项、何时排期由需求管理流程决定。这样两份文档各司其职，修订时也不会互相牵制。
完成标志是：团队新成员读完这份范围说明，能判断自己手上的需求该不该用用户故事模板，遇到边界模糊的需求知道找谁确认。
用户故事的标准结构与字段定义
字段定义表是规范的主体。它把一条用户故事拆成可填写的若干项，每项写明含义、是否必填、由谁填写，并给出一句示例。字段不宜多，控制在评审时能逐项看完的数量；字段太少，验收条件、优先级这些关键信息就会散落在聊天记录里。
故事主体建议采用“作为（角色），我希望（目标），以便（价值）”的句式。三个成分各有作用：角色说明谁在使用，目标说明要完成什么动作，价值说明为什么值得做。价值部分常被写成“以便提升效率”，这类表述无法评审，规范中应要求写出具体的业务结果，例如“以便财务在月底前完成对账”。
验收条件建议采用“给定—当—则”的结构，每条对应一个可验证的场景。数量上不设固定上限，但要求覆盖正常路径和关键异常路径，评审时能逐条判断通过与否。验收条件由产品经理起草，测试在评审中补充遗漏的边界场景。
下表可作为字段定义表的起点，团队按实际情况增删：
| 字段名 | 说明 | 必填/选填 | 填写人 | 示例 |
|---|---|---|---|---|
| 故事标题 | 一句话概括故事目标，便于列表识别 | 必填 | 产品经理 | 财务按项目导出对账单 |
| 角色 | 使用该功能的用户角色 | 必填 | 产品经理 | 财务专员 |
| 目标 | 用户要完成的动作 | 必填 | 产品经理 | 按项目筛选并导出月度对账单 |
| 价值 | 完成后的业务结果 | 必填 | 产品经理 | 月底对账时间从两天缩短到半天 |
| 验收条件 | 可逐条验证的场景，含正常与异常路径 | 必填 | 产品经理起草，测试补充 | 给定存在未结清项目，当选择该项目导出，则对账单仅包含未结清明细 |
| 优先级 | 排序依据与等级 | 必填 | 产品经理 | 高：影响本月结账 |
| 估算 | 相对工作量，单位由团队约定 | 选填 | 开发 | 3 点 |
| 关联信息 | 关联的需求来源、设计稿或依赖项 | 选填 | 产品经理 | 关联客户反馈单号与对账单设计稿 |
| 拆分说明 | 从哪个大故事拆出、与其他子故事的关系 | 选填 | 产品经理 | 由“财务对账自动化”拆出，本故事负责导出环节 |
必填与选填的划分要服务于评审：必填项缺失时故事不能进入评审，选填项允许在评审后补齐。估算由开发在评审时填写，规范中应说明它不参与需求是否成立的判断，只用于排期参考。字段定义表定稿后，建议同步做成文档模板，让填写人打开即见结构，减少格式来回沟通。
拆分粒度、优先级与状态流转规则
粒度规则回答“一个故事多大算合适”。常用的判断依据是：能在一个迭代内由一名开发完成，验收条件可以在一次评审中逐条确认，故事交付后能独立产生可观察的用户价值。三条同时满足即可视为合适；只满足前两条而无法独立交付的，通常还需要继续拆分或与相邻故事合并。
拆分时优先按用户操作路径拆，例如“筛选—预览—导出”各成一条；其次按角色或场景拆。拆分后每个子故事仍要保留完整的角色、目标和价值，避免出现“前端部分”“后端接口”这类按技术层拆出的故事，它们无法独立验收。
超大故事的识别可以设一个简单信号：验收条件超过团队约定的条数，或估算明显高于一个迭代的容量，或评审时无法在一次会议内讨论完。出现这些信号时，规范要求产品经理在评审前完成拆分，而不是带着超大故事进入评审再现场拆。
优先级标注建议采用“等级加依据”的方式，等级用高、中、低或团队惯用的数字序列，依据写清来源，例如客户合同约定、结账周期、依赖的其他故事。只标等级不写依据，排序争议时无法回溯。优先级由产品经理提出，评审中与开发和业务方确认。
状态流转规则要让每个节点有准入条件，下表可作为模板：
| 状态 | 准入条件 | 责任人 |
|---|---|---|
| 草稿 | 故事主体已填写，验收条件待补 | 产品经理 |
| 待评审 | 必填字段完整，验收条件覆盖正常与异常路径 | 产品经理 |
| 已评审 | 开发与测试确认可理解、可估算，评审意见已处理 | 产品经理、开发、测试 |
| 开发中 | 已排入迭代，关联设计与依赖项明确 | 开发 |
| 待验收 | 开发完成，验收条件逐条自测通过 | 开发、测试 |
| 已完成 | 验收条件全部通过，遗留问题已记录 | 产品经理、测试 |
状态规则落地到工具时，需要工作项支持自定义字段与状态流转。ONES 的需求工作项可以把上述字段作为条目属性维护，状态变更与评审记录留在同一条目下，评审时不必在文档和任务列表之间来回对照；具体字段与流转配置能力以实际产品版本为准。
角色分工与交付物：谁写、谁评审、谁验收
规范能否执行，取决于每个环节是否有人负责、有明确产出。建议把职责写成矩阵，按编写、评审、验收三个环节列出输入、动作和输出，避免“大家一起把关”这类无法追责的表述。
| 角色 | 编写环节 | 评审环节 | 验收环节 |
|---|---|---|---|
| 产品经理 | 起草故事主体、验收条件、优先级，完成必填字段 | 主持评审，记录并处理评审意见 | 确认验收结果符合业务预期 |
| 开发 | 提供技术可行性输入，标注依赖项 | 判断故事是否可理解、可估算，提出拆分建议 | 完成自测并提交待验收 |
| 测试 | 提前阅读验收条件，准备测试场景 | 补充异常路径与边界场景 | 按验收条件逐条验证并记录结果 |
| 设计 | 涉及交互的需求提供设计稿或交互说明 | 确认交互方案与故事描述一致 | 参与界面相关故事的验收 |
三个环节的交付物分别是：编写环节产出字段完整的待评审故事；评审环节产出评审结论，包括通过、修改后通过、退回重写三种；验收环节产出验收记录，注明每条验收条件的通过情况。评审结论要写进故事条目本身，而不是只留在会议纪要里，后续回溯时才能看到当时的判断依据。
评审不通过时，规范应给出处理路径：属于字段缺失或表述不清的，退回产品经理补充，不占用新的评审时间；属于范围过大或价值不清的，退回重新拆分或补充业务依据；属于技术可行性存疑的，由开发在评审中给出替代方案，产品经理确认后更新故事。每条退回意见指定处理人和期望完成时间，避免故事长期停在待评审状态。
规范文档本身的承载也值得安排。团队可以把规范、字段模板和示例库放在同一个文档空间，按角色配置读写权限，让产品经理可编辑、其他角色可评论。ONES Wiki 支持页面模板库一键创建制式化文档，页面组可关联项目，文档版本可查看与回滚，适合把规范与示例作为团队共同维护的知识资产；具体权限粒度与版本能力以实际版本为准。
示例：一条符合规范的用户故事长什么样
下面用一条完整示例演示各字段如何填写。场景为演示用途，团队可按自己的业务替换。
故事标题：财务按项目导出月度对账单
故事主体：作为财务专员，我希望按项目筛选并导出月度对账单，以便在月底结账前完成项目费用核对。
验收条件：
- 给定当前月份存在未结清项目，当选择单个项目并导出，则对账单仅包含该项目的未结清明细，金额合计与明细一致。
- 给定所选项目当月无交易记录，当执行导出，则提示无数据并保留筛选条件，不生成空文件。
- 给定导出文件已生成，当用表格软件打开，则日期、金额、项目名称三列格式统一，金额保留两位小数。
优先级：高。依据：本月结账依赖该功能，且已有三个项目组提出相同诉求。
估算：3 点，由开发在评审时填写。
拆分说明：由“财务对账自动化”拆出，本故事负责筛选与导出环节，对账差异比对另立故事。
逐项看，这条示例符合规范的原因在于：角色、目标、价值三者具体且可对应到业务动作；验收条件覆盖正常路径、无数据路径和文件格式要求，每条都能由测试独立判断；优先级写明了依据来源；拆分说明交代了与其他故事的关系，评审时不会误以为它要覆盖整个对账流程。
常见错误写法有三类。第一类是把技术实现写进故事主体，例如“作为系统，我希望调用对账接口”，角色变成系统，价值无法验证，修正方向是回到使用该功能的人及其业务目标。第二类是验收条件写成“功能正常可用”，无法逐条判断，修正方向是改写成给定—当—则的具体场景。第三类是故事过大，一条故事同时包含筛选、导出、差异比对和通知，评审时无法估算，修正方向是按操作路径拆成多条，每条独立可验收。
完成检查：规范发布前的自查清单
规范写完后，先按清单自查一遍再发布。检查的重点是文档是否完整、字段是否真的能填、评审是否真的能判，而不是篇幅是否够长。
文档完整性检查项：
- 适用范围说明已写明覆盖与排除的需求类型，并说明与需求管理流程文档的关系。
- 字段定义表包含字段名、说明、必填/选填、填写人和示例五列，无空缺。
- 粒度判断标准、优先级规则、状态流转表均已写入，状态表每个节点有准入条件。
- 角色职责矩阵覆盖编写、评审、验收三个环节，每个环节有明确交付物。
- 至少有一条完整示例和两到三条错误写法对照。
可执行性检查项：
- 找一位未参与制定的产品经理，按字段表填写一条真实故事，能在不额外询问的情况下填完必填项。
- 找一位开发和一位测试，按验收条件判断一条故事能否通过评审，两人结论一致。
- 按状态流转表走一遍，确认每个状态的准入条件都能被客观判断，不存在“视情况而定”的节点。
- 确认评审不通过的处理路径有指定处理人和时限。
试点与修订安排：规范建议先在两到三个迭代内试用，记录填写耗时、评审退回原因和高频争议点。试点结束时集中修订一次，把反复出现的填写问题补进示例库，把判断不清的规则改写成可核验的条件。修订记录保留在文档版本中，便于团队了解规则变化。
维护责任与更新频率：指定一名规范负责人，通常由产品负责人或需求管理负责人担任，负责收集反馈和发起修订。建议每个季度检查一次，遇到需求流程调整、团队角色变化或工具字段变更时随时更新。更新后在团队例会上说明变更点，避免成员继续按旧版本填写。
规范发布后，团队可以借助 ONES Wiki 的模板库把字段表固化为文档模板，新故事按模板创建；评审意见和状态变更留在对应需求条目下，规范文档与需求条目通过页面组关联项目保持对应。这样规范不只是一份静态文档，而是随每次填写和评审被实际使用的约定。
常见问题
团队规模很小，还需要单独制定用户故事编写规范吗？
小团队同样需要规范，但可以更轻。字段表保留故事主体、验收条件、优先级三项必填即可，估算和关联信息作为选填；状态流转可以压缩为草稿、待评审、开发中、已完成四个节点。规范篇幅控制在一两页，重点是让评审时有共同判断依据，而不是照搬大团队的完整流程。团队扩大或需求来源变多时，再逐步补充字段和节点。
规范里的验收条件应该写到多细？
判断标准是测试能否据此独立判断通过与否。每条验收条件对应一个可验证场景，覆盖正常路径和关键异常路径，例如无数据、权限不足、格式要求。写到“金额保留两位小数”“无数据时不生成空文件”这类可观察结果即可，不必写到接口参数或数据库字段。验收条件由产品经理起草，测试在评审中补充遗漏的边界场景，两边对同一条故事的理解一致，才算写到位。
规范发布后，成员仍按旧习惯填写怎么办？
先检查规范是否真的可执行：找一位未参与制定的产品经理按字段表填一条真实故事，如果填不完或需要反复询问，说明字段或说明本身有问题，应先修订文档。文档没问题时，把规范做成文档模板，新故事按模板创建，必填项缺失的故事不进入评审；评审会上按检查清单逐项对照，退回意见写进故事条目。试点期的两三个迭代内集中纠正，比长期口头提醒更有效。
规范文档应该放在哪里维护，和需求条目怎么对应？
建议把规范、字段模板和示例库放在同一个文档空间，按角色配置读写权限，产品经理可编辑、其他角色可评论。ONES Wiki 支持页面模板库一键创建制式化文档，页面组可关联项目，文档版本可查看与回滚，适合把规范作为团队共同维护的知识资产；具体权限粒度与版本能力以实际产品版本为准。评审意见和状态变更则留在对应需求条目下，文档与条目通过项目关联保持对应。
规范需要多久修订一次，谁来负责？
指定一名规范负责人，通常由产品负责人或需求管理负责人担任，负责收集反馈和发起修订。常规检查建议每季度一次；遇到需求管理流程调整、团队角色变化或工具字段变更时随时更新。修订时保留版本记录，在团队例会上说明变更点，避免成员继续按旧版本填写。试点结束后的第一次集中修订最关键，应把反复出现的填写问题和判断不清的规则一并改掉。
