写出承载意图的用户故事，而不只是任务
只要接触过Scrum，你就见过这种格式："作为用户，我想要一个按钮，以便我能点击它。"它把格子都打上了勾，却什么也没教会人。用户故事的本意是把意图——一项请求背后的、属于人的理由——带进工作之中，好让一名要做出上百个小抉择的开发者，把每一个都朝着正确的方向去做。意图一旦缺失，团队就会一字不差地照写的去做，却仍然没有抓住要点。
《Scrum指南》其实并不要求用户故事。它谈的是产品待办列表项以及产品待办列表本身。用户故事只是表达这些条目的一种流行技巧，而非规则。这个区别很重要：目标是让一份开发者能看懂、产品负责人能按价值排序的待办列表，而故事格式不过是抵达这一目标的可靠途径。
真正要紧的三个部分
一个有用的故事回答三个问题。这是为谁做的？他们想要能够做什么？以及这为什么对他们重要？经典的"作为/我想要/以便"模板之所以存在，就是为了逼出第三个问题——也正是团队最常丢掉的那一个。价值就藏在"以便"里。没有它的故事，是一项乔装打扮的任务。
看看其中的差别。"作为工地负责人，我想把日志导出为PDF"是一项任务。"作为工地负责人，我想把日志导出为PDF，以便我能给检查员一份记录，而不必让他们访问系统"则告诉团队成功是什么样子，并打开了更好的解决方案。也许真正的需求是一个只读分享链接，而根本不是PDF。
如何写出经得住推敲的故事
把它锚定到一个真实的人。 写出真正的角色，而不是含糊的"用户"。采购负责人和一线工人想要的东西不同；故事应说清是哪一个。
先讲结果，而非界面。 描述这个人需要完成什么，给团队留出空间去找出最佳的交付方式。过早规定界面，等于浪费了他们的专业能力。
加上验收标准，而不是设计稿。 列出让故事算作完成的条件——评审者可以核实的检查点。它们让"以便"变得可验证，又不替实现方式拍板。
让它小到能够完成。 如果一个故事在一个Sprint里多半完不成，就按它交付的价值去拆分，而不是按技术分层去拆。两片各自能用的薄切片，胜过一片只完成一半的厚切片。
共同精化它。 待办列表精化正是团队提问、产品负责人澄清的时刻。故事是一段对话的占位符，而不是自上而下交下来的合同。
故事失去意图的迹象
每个故事都写着同一个笼统的"用户"，以致没人能想象到底是谁受到影响。
"以便"从句只是把"我想要"换了个说法——"以便我能导出"——多了字词，却没有理由。
故事把按钮、字段和布局都定死，让团队只管敲键盘，而不必思考。
它大到一个Sprint里完不成，却一直原封不动地往后滚。
在2022年，团队分散在家中与办公室之间，预算又被上涨的成本挤压，做错东西的代价比以往更高。一个承载意图的用户故事是一份廉价的保险：它让一名晚上九点独自工作的开发者，做出与产品负责人会做的相同的判断。把它写下来，意义全在于此。
如果你的团队想要能驱动价值、而不只是罗列任务的待办列表，XNM的项目群与项目交付咨询可以帮你把工作的表述打磨得更锋利。