你的用户故事有意图吗？一场并排对比
当团队在 2020 年转为远程办公、并一直混合办公到 2021 年时，许多待办列表中浮现出一个隐蔽的问题。由于减少了走廊闲聊来弥补缺口，卡片上的文字必须承担更多。一个过去因为有人能隔桌询问而得以存活的用户故事，如今却因无人明白其真正含义而停滞。解决之道不是更多仪式，而是写出承载意图的故事。
Scrum 本身几乎没有规定如何编写产品待办列表项。《Scrum 指南》将格式交由团队自行选择。用户故事只是最流行的约定，而那个常见模板——作为[角色]，我希望[能力]，以便[结果]——只有在第三个子句诚实时才有用。去掉“以便”，你剩下的只是一个披着敏捷外衣的功能请求。
一个薄弱的故事是什么样
薄弱的故事描述的是界面，而非需求。它们把解决方案塞进需求里，于是团队严格按照所写内容构建，却为时已晚地发现它什么也没解决。它们往往有几个共同特征。
“作为用户，我想要一个省份下拉菜单。”——这是个控件，不是目标。用户为什么需要选择省份？
“作为管理员，我想要一份报表。”——没有结果，没有范围。这份报表支撑哪个决策？
“作为客户，我希望系统快一点。”——真实的需求，但无法验证。与什么相比算快，怎么衡量？
一个庞大到永远无法在一个冲刺内完成的故事，拖了三个冲刺，堵住了后面所有工作。
一个坚实的故事是什么样
坚实的故事点明一个人、一项能力，以及使这项能力值得构建的结果——然后留出空间让团队决定怎么做。它足够小以便完成，并附有验收标准告诉你何时算完成。
它陈述一个真实的结果。 “作为现场监工，我想标记一批到货为缺交，以便采购能在下一次浇筑前催促供应商。”这个“以便”可验证，且与一个决策相连。
它独立且可协商。 卡片开启一场对话，而非结束它。监工与开发人员仍可讨论是标记、照片还是数量字段最能服务于这个目标。
它小且可验证。 它能装进一个冲刺，并附有验收标准——“该标记在一次刷新内出现在采购仪表板上”——因此“完成”不是观点问题。
即使作者不在场也能立住。 三个时区之外的远程同事能凭空读懂并构建出正确的东西。这才是意图的真正检验。
请注意，那个坚实的例子来自 2021 年的供应链世界：缺交、错过浇筑、需要催促的供应商。这个故事承载了意图，因为它描述的是某人试图达成什么，而不是该渲染哪个控件。让“为什么”保持可见，待办列表的其余讨论就会变得更容易——估算、拆分和优先级排序都依托于一个团队真正能看见的目标。
细化之前的快速检验
在把一个故事拉进冲刺之前，用两个问题考验它。第一，你能否在不提及任何界面、按钮或数据库表的情况下说出这个结果？如果不能，你手里拿着的是一个解决方案，而非一项需求，你也关上了团队本可带来的更好点子的大门。第二，一位从未见过提出者的开发人员，仅凭这张卡片能否构建出正确的东西？如果诚实的答案是否定的，那么意图就活在某人的脑子里，而不在卡片上——在一个分布式团队里，当工作开始时，那个脑袋可能正好不在线。
这一切都无需更沉重的流程。一个好故事往往比一个坏故事更短，因为它不再描述界面，而开始点明目标。验收标准负责精确性的活儿；故事本身只需让目的清晰无误。当意图写在卡片上，细化就变成一场关于最佳解决方案的对话，而不是一次对提出者究竟想表达什么的考古发掘。
如果你的待办列表充满的是界面而非结果，XNM 的项目与项目群交付咨询 可以帮助你的团队写出承载意图、能经受交接考验的需求。