用户故事：如何写好它们的初学者指南
用户故事是从将使用它的用户角度对功能的简短、非正式描述。标准格式是：「作为[用户类型]，我想要[某个目标]，以便[某个原因]。」用户故事是在Scrum中在产品待办列表中捕获工作的主要方式。它们故意简短——三部分格式提醒我们工作是为了服务用户需求而存在，而非本身的目的。
用户故事是什么（以及不是什么）
用户故事不是完整的需求规格说明。它是对话的邀请。故事捕获谁、什么和为什么——足以就如何进行对话。伴随故事的验收标准捕获必须满足才能认为故事完成的具体条件。没有验收标准的用户故事是不完整的。用户故事不是任务。任务是团队完成的工作单元。用户故事是交付给用户的价值单元。
好用户故事的INVEST标准
独立的（Independent）。 故事应该相互独立，这样它们可以以任何顺序开发和交付。具有强依赖关系的故事更难优先排序和调度。
可协商的（Negotiable）。 故事不是固定的合同。故事实施方式的细节在产品负责人和开发团队之间是可协商的。
有价值的（Valuable）。 每个故事都应该为用户或客户提供价值。如果价值不清晰，故事应该被修订或丢弃。
可估算的（Estimable）。 团队应该能够估算故事。无法估算的故事要么太大，要么理解得不够充分。
小的（Small）。 故事应该足够小，能在一个Sprint内完成。太大的故事称为史诗，应该被分解。
可测试的（Testable）。 故事应该有定义完成含义的验收标准。如果故事无法测试，就无法验证为已完成。
常见用户故事错误
从开发人员的角度而非用户的角度写作。「作为开发人员，我想重构身份验证模块以便……」是任务，而非用户故事。重构工作应该作为技术故事跟踪，清楚地标记，并由产品负责人与面向用户的故事一起优先排序。
省略「以便」条款。用户想要功能的原因是开发团队的关键背景。「作为经理，我想将报告导出到Excel，以便与没有系统访问权限的利益相关者共享」告诉团队功能为什么重要，并可能揭示实现目标的更好方法。
写太大的故事。将占据整个Sprint或更多时间的史诗不是故事——它是功能。将其分解为更小的故事，每个故事本身都能提供价值。
将用户故事与验收标准混淆。用户故事描述意图；验收标准描述验证条件。两者都是必需的。
XNM为公共部门组织提供Scrum辅导和敏捷交付顾问服务。欢迎联系XNM项目群与项目交付咨询团队，探讨贵组织的用户故事实践和Scrum实施。