写出冲刺当天依然有意义的用户故事
《Scrum 指南》从未提及用户故事——它们并不属于 Scrum 本身，只是表达产品待办列表项的一种流行方式。这一点很重要，因为它让你得以善用故事，而不是机械照搬。一个好的用户故事并非微型规格说明。用 Ron Jeffries 的话说，它是一次对话的占位符：简短地说明谁、需要什么、为什么，足以据此做计划，细节则等团队与产品负责人真正交谈时再补全。在分布式团队中，这场对话如今发生在视频通话里，而不再是在工位旁，因此故事本身必须承载更多意图。下面是一份帮你写出这类故事的清单。
在故事进入冲刺之前
点明真实的用户。「作为用户」什么也没说。「作为夜班调度员」却道出了情境、约束，以及「完成」会是什么感觉。
说出为什么，而不只是做什么。「以便」那一句正是价值所在。如果你补不出来，也许你正在做没人要的东西。
让它独立产生价值。一个故事应当交付用户能用的东西，而不是要等另外三个故事落地才有用的技术层。
加上团队共同认可的验收标准。这些是让故事「完成」的条件——具体、可测试，在动工前写好，而不是评审时临时编出来的。
对每个故事做一次快速检验
它小到能在一个冲刺内完成吗？ 如果团队看不出它能在一个冲刺内做完，就沿着用户可见的维度去拆分，而不是按技术维度拆。
作者以外的人能估算它吗？ 如果只有撰写者看得懂，那么故事本该建立的共同理解还不存在。
它是否避免规定解决方案？ 陈述需求和结果，把「怎么做」留给开发人员。一个规定实现方式的故事，等于浪费了他们的专长。
验收标准可测试吗？ 「运行良好」不是标准。「在一万行的搜索中两秒内返回结果」才是。
对一个陌生人来说，价值是否依然一目了然？ 以一个错过了那场对话的人的视角去读它。如果意图还在，故事就承载住了它。
故事不是什么
它不是一份免去团队交谈义务的合同。它不是用来塞下一整份需求文档的地方。它也不是产品负责人私藏的待办清单——产品待办列表的全部意义，就在于它透明、并由大家共同精炼。这里的纪律在于克制：只写到足以让那场正确的对话发生，把共识落在验收标准里，并克制住把每个细节都预先写死的冲动。承载意图的故事，让团队做出用户需要的东西，而不仅仅是工单上描述的东西。
如果你的待办列表已经沦为一堆无人信任的工单，XNM 的项目群与项目交付咨询服务 可以帮助你的团队写出能推动工作、而不只是记录工作的故事。