用户故事必须完整，任务必须彻底完成（如何写用户故事3）

在你撰写用户故事或列出待办事项清单时，有两个问题很重要：用户故事够完整吗？你如何才能知道自己已经完成了任务？

比如，我们看一看斯托尔写的用户故事：“作为特种部队的医生，我必须为学生们传授基本的生理学知识，这样他们才能了解人体。”

关于一则用户故事是否完整，我经常用一套标准来衡量。这套标准是比尔·韦克（Bill Wake）发明的。他认为，一个好的用户故事应该满足 INVEST 标准：

• • 可协商性（Negotiable）——用户故事的内容要是可以协商的，用户故事不是合同。一张用户故事卡片上只是一个简短的描述，不包括太多的细节。具体的细节在沟通阶段提出。如果一张用户故事卡片带有太多的细节，实际上会限制和用户的沟通。
  • 有价值（Valuable）——每个用户故事必须对客户具有价值。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事，并不是一个契约，而且可以进行协商的时候，他们将非常乐意写下故事。
  • 可评估（Estimable）——开发团队需要衡量用户故事，以便确定优先级和工作量，并便于安排工作计划。
  • 规模小（Small）——一个好的故事要尽量维持小规模，至少要确保在一个Sprint周期中能够完成。用户故事越大，在安排计划、工作量评估等方面的风险就会越大。
  • 可测试（Testable）——一个用户故事要可以测试，以便确定它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。

斯托尔的故事是独立的，因为他的学生们就在老挝，他不必考虑学生们前往老挝所需的直升机燃油费之类的事情，他能够独立完成任务。

他的故事是可修改的，因为虽然他一开始打算为学生们传授基本的生理学知识，但如果他到了那里之后发现学生们已经具备这样的知识，或是已经有了一定的了解，那么他有其他的教学方法可以用。他的故事有价值：学生们学到人体知识之后，可以派得上用场。他的故事规模小：他只给学生们传授基本的解剖学知识，而不是教他们运用这些知识去开展外科手术。他的故事可测试：他很清楚自己想要传递的信息，也可以对学生开展一些小的测试，以便确认他们是否真的吸收了这些信息。

每个有待落实的用户故事都应该要有“完整”的定义（比如是否符合INVEST标准），同样，最后的结果也要符合“完成的定义”（比如必须符合什么条件、通过什么测试才能结束等）。在现实中，我们发现，如果用户故事足够完整，那么团队在落实项目的过程中速度就会加快一倍。此外，如果一个阶段的Sprint完成了相应的用户故事，那么，这个团队的速度会再次加快一倍。这就是我们能够达到事半功倍之效的一个原因。

来源：《敏捷革命：提升个人创造力与企业效率的全新协作模式》  【美】Jeff Sutherland  Scrum之父作品

该书的PDF版本我有上传，如需要可自行下载。

不要盲目执行任务，要领会用户故事（如何写用户故事1）

用户故事宜短不宜长（如何写用户故事2）