用户故事 同时是敏捷领域中被写入最多和被跳过最多的工件。大多数团队编写它们是因为模板需要它。大多数团队都会忽视他们 站立 因为他们实际上并没有塑造作品。
这是实用版本。 INVEST 清单列出了最敏捷的培训参考资料，但很少以具体术语进行教学。好的故事和坏的故事并排看起来是什么样子的。角色模板之争。这条规则可以通过一个习惯解决 80% 的工单质量问题。
“作为……我想要……以便……”模板；什么时候有帮助，什么时候撒谎
经典格式：
作为一个[角色]，我想要[功能]以便[利益]。
这个模板是 有用的 分两种情况：
- 该团队尚不清楚这项工作是为谁而做。强迫角色让你面对这个问题。
- 团队并不清楚这项工作为何如此重要。强迫“这样”会让你面对这个问题。
模板是 无用的 分三种情况：
- 作用和好处是显而易见的。 “作为一个已登录的用户，我想注销，这样我就可以停止登录”；是的，好吧，我们都知道。该模板添加噪声而不添加信号。
- 作用和好处是 假的。编写故事的工程师经常发明一个听起来合理的角色/利益来满足格式，然后忽略两者。 “作为系统管理员，我想要数据库连接池，以便提高性能。”没有人检查系统管理员是否想要这样。这是一项内部任务。
- 这个故事是一件苦差事，而不是一个特色。 “将 Rails 升级到 7.1。”没有面向用户的好处；利益是内部的。强制使用用户故事格式会让作者撒谎。
解决办法：写任何能清楚表达工作内容的内容。当它使思维更加敏锐时就使用模板，当它增加仪式感时就放弃它。
投资、应用
INVEST 是最常被引用的故事质量缩写：独立、可协商、有价值、可估计、小型、可测试。大多数培训都是抽象地呈现它。这是每个的实用版本，以及要问的问题。
我；独立
这个故事可以按任何顺序进行，而不依赖于一个单独的尚未完成的故事吗？
测试：“如果我们单独选择这个故事，没有其他内容 待办列表，我们能完成吗？”
如果不是，则依赖关系必须是明确的（链接工单），或者需要将故事与其依赖关系合并。隐藏的依赖关系是冲刺中期的发现破坏目标一致性的原因。
常见失败：“添加缓存层”依赖于“迁移到新的 Postgres 实例”，但没有这么说。在冲刺中期，工程师意识到订单很重要。冲刺目标落空。
N;面议
是 结果 固定但 实施 打开？或者这个故事是一个循序渐进的处方？
测试：“两个不同的工程师能否以两种不同的方式讲述这个故事并且都满足目标？”
如果不是，则该故事是伪装成故事的任务列表。有时这很好（合规性工作、回归测试），但这不是一个故事；它是一个故事。这是一个食谱。当它没有打开时，不要假装它是打开的。
常见失败：14 的故事 验收标准 读起来就像一个实施计划。团队没有空间寻找更好的解决方案。
五；有价值
这个故事是否产生了利益相关者可以称之为价值的东西？
测试：“如果我们在这个冲刺中只发布这个故事，我们可以指出一个好处和受益人吗？”
如果不是，这个故事可能是其他任务的子任务。要么将其与父故事合并，要么诚实地承认它是支持工作，而不是可交付的工作，并接受它不应该成为冲刺的标题。
常见故障：“重构结帐控制器”；就其本身而言，没有用户看到差异。它正在启用。有价值的故事是“将结帐错误率降低到 0.5%”，而重构是实现这一目标的一种可能途径。
E;可估价
团队能否就大致尺寸达成一致？
测试：“三个工程师看着这个并说小/中/大。他们在一个桶内是否同意？”
如果不是，那么这个故事就有太多的不确定性。团队了解不够，无法做出承诺。要么投资于 细化 （研究、原型、分解）或者不要将其放入冲刺中。
常见故障：“添加实时通知”；没有关于在哪里、如何、什么触发它们以及故障模式是什么的规范。估计值在“1 天”和“3 个冲刺”之间徘徊。
S；小号
这个故事是否适合一次冲刺？最好是 2-5 天？
测试：“即使有正常的中断，一个工程师（或一对）可以在冲刺内完成这个任务吗？”
如果没有， 拆分它。超过半个冲刺的故事是团队未能实现目标的最大原因；它们无法暂停、并行化或降低风险。
常见失败：在 30 点冲刺中，故事大小为“13 点”或“20 点”。他们消耗了团队两周的时间；如果出现任何问题，冲刺就会消失。
T；可测试
是否有一个清晰、可观察的检查来确定故事是否完成？
测试：“工程师能否在没有解释的情况下演示完成度？”
如果不是，则需要制定验收标准。 “应该感觉敏捷”是无法测试的。 “页面加载时间低于 800 毫秒 p95”。参见 验收标准格式 适合不同工作类型的五种格式。
常见故障：工单中“完成”的内容是工程师认为正确的内容。 PR 审核成为唯一的检查，审核者没有时间验证功能行为。
并列：坏故事→好故事
实施例1；特征
不好:
添加用户个人资料图片支持。
好:
作为活跃用户，我想上传个人资料图片，以便在繁忙的线程中可以识别我的评论。
验收：
- 从配置文件设置页面上传最多 2MB 的 PNG/JPG
- 上传后 30 秒内，图片会出现在评论中我的显示名称旁边
- 旧图片被替换（无孤儿存储）
- 如果没有上传则显示默认头像
非目标：裁剪 UI、多张图片、动画图像。
好的版本是可测试的、小（1-2天）、有价值的、有明确的范围。 “无目标”路线节省了一个小时的辩论。
实施例2；基础设施/平台
不好:
提高 API 性能。
好:
减少 P95 延迟
GET /api/v1/issues从 850 毫秒到 300 毫秒以下。验收：
- 24小时300ms以下滚动P95投入生产
- P99无退化（当前为1.4s，必须保持≤1.6s）
- /api/v1/issues/* 同级端点上没有回归
实施指导：可能是受让人预加载的 N+1，但工程师可以自由选择。
好的版本有具体的结果、可衡量的接受度以及 流通性;工程师选择实施。
实施例3；错误
不好:
登录有时会被破坏。
好:
4-6% 的用户在高峰时段（英国下午 2-4 点）登录超时，特别是帐户中冲刺次数超过 500 次的用户。
验收：
- 95% 的登录时间在 2 秒以内，包括高峰时段
- 使用种子数据可在分期中重现；复制脚本已提交
- 公关描述中确定并指出了根本原因
测试数据：参见暂存帐户
loadtest-1.
好的版本是可重复的，具有清晰的可测量性，包括不明显的细节（片段+一天中的时间），以防止工程师追寻错误的原因。
30秒规则修复80%的工单质量
在将故事接受到冲刺之前，团队中的任何人都应该能够在 30 秒内阅读它并回答：
- 结果如何？
- 我们如何知道它已经完成？
- 什么是 不 在范围内？
如果在工单中找到任何答案的时间超过 5 秒，则工单尚未准备好。现在重写（15 分钟）或从冲刺中删除它。您将在冲刺中节省 4 倍的时间。
一旦团队采用这一点，就会产生三个后续后果：
- 精炼变成 30 分钟的会议，而不是 90 分钟的会议，因为大多数故事都已经结构化。
- 冲刺计划需要一半的时间，因为团队在计划时没有写票。
- 冲刺中期“等等，这是什么意思？”对话量下降约 70%。
反模式一见就杀
一些故事模式总是表明冲刺的输入错误：
转储段落的故事。 400字的上下文，没有接受标准，没有明确的范围。通常，利益相关者粘贴 Slack 消息，然后有人用它制作工单。
17 条录取标准的故事。要么故事太大（将其拆分），要么标准伪装成规范（将它们推入链接的设计文档并引用它）。
“待定”的故事。 “验收标准：待定。”故事还没准备好。不要拿着 TBD 工单冲刺开始。
连锁错误修复故事。 “修复 X、Y、Z、A、B、C。”每张票都有自己的工单。标题中有五个症状的故事就是五个故事。
“我们会解决这个问题”的故事。工程师说：“我会边走边解决。”有时对于尖峰有效（称之为尖峰，时间限制）。对于功能工作几乎总是无效。
如何在计划时进行 5 分钟的故事质量检查
如果您团队的故事不一致，请将其添加到冲刺计划中：
对于每个候选人的故事：
- 大声朗读标题。如果有人问“等等，什么？”，请标记它。
- 一个人阅读验收标准。如果他们在 30 秒内无法阅读，请标记出来。
- 问“什么是 不 范围内？”如果答案是“未指定任何内容”，请标记它。
被标记的故事在被重写之前不会进入冲刺。这听起来很有侵略性。它节省的时间比第一周花费的时间还要多。
总结
- 使用角色模板可以提高思维能力；当它增加噪音时将其丢弃。
- 具体应用时INVEST是决定性的；独立、可协商、有价值、可评估、小型、可测试。
- 30 秒的测试（结果、完成测试、超出范围）捕获 80% 的不良工单。
- 拒绝的五种反模式：转储段落、17 个标准、待定、链式错误、“我们会弄清楚的”。
故事不是文献资料，而是文献。它们是一种对齐工具。如果他们不协调团队，那么他们唯一的工作就失败了。
根据速率跟踪故事大小？ SprintFlint 自动计算滚动速率、完成分数、命中率；没有电子表格漂移。 免费试用：每月50张免费工单，无需刷卡。