本文核心观点来自《敏捷革命》
在工作中，多数人都只是一个被动的执行者。比如，现在让你调查北京市近期卖了多少小龙虾，没有人告诉你为什么要做这件事，你可能会理解偏差，以至于提供错误的数据，甚至对于领导指派给你这种“毫无意义”的工作感到不满。
如果换个说法：作为水产供应商，我想要了解近三个月北京市小龙虾的销售情况，以便安排后期的货源。这种说法是不是明确多了？
工作中无谓的消耗时间是最可怕的。往往员工没有得到足够的信息，而上司也没有为下属提供足够的信息。要知道，人们习惯于用情节、故事去思考问题。大家都是这样来理解世界的。我们比较容易掌握人物、欲望及动机等，当我们试图把个别片段从主线中剥离出来，脱离具体语境去理解它们时，就会出现问题。
“Scrum之父”萨瑟兰博士在《敏捷革命》中，提倡要学会写“用户故事”。用户故事是从用户的角度来描述用户渴望得到的功能，这种方法不仅仅可以用在产品设计上，也可以用在每一个人的工作中，它能帮你确定目标，完成意志、动机、决心的统一和实践，避免徒劳无功的浪费。
不要盲目执行，要学会写用户故事
当你面对一项任务时，要学会从用户的角度来描述用户渴望得到的功能，也就是要学会写“用户故事”，比如作为X，我想要Y，所以Z。
一个好的用故事包括三个要素：
第一个要素是角色
包括顾客、读者、员工、老板等，这就要求我们思考：谁要使用这个功能？这项任务是为“谁”而做的？打造这样东西、做这项决策、提交这项成果，我们应该从谁的角度出发？
第二个要素是活动
要求我们思考我们要完成什么样的功能。这通常是我们的出发点，也是落脚点。
第三个要素是商业价值
或者说动机。要求我们思考客户为什么需要这个功能，以及这个功能如何才能给客户创造价值。从某种角度来看，这是最重要的一步。动机重于一切。
需求往往会因为人物的不同而改变。比如，一则故事的后半部分是：“……我想要一辆车，以便开车上班。”假如这则故事的前半部分有两个版本：一个是“我是住在郊区的通勤族”，另一个是“我是居住在南达科他州荒芜之地的农民”，那么，你对于这个人心目中理想的车型，就会有截然不同的解读。
因此，在确定待办事项的优先顺序之前，必须先考虑一下有关的人物、使用者或客户，也就是说你的劳动成果将由谁来使用。你要了解他们的喜好、厌恶、激情、热情、沮丧及喜悦是什么，他们的使用动机是什么，以及用户类型对于自身需求的影响。他们为什么需要汽车？他们用舰长日志做什么？这也会影响你对事情的评估。比如，如果他们需要的只是一般日历功能，那就简单了，如果他们需要的是可用于法律目的的、不容更改的日历功能，那就有点棘手了。
用户故事宜短不宜长
用户故事宜短不宜长，以便于对其进行评估。试想一下，如果亚马逊让你设计产品，你会怎样撰写它的用户故事。你可能会写道：“用户想要一家全球最大的在线书店，这样用户随时都能买到想要的书。”这个用户故事的确概括了亚马逊的情况，但太宽泛，不具有指导意义，必须分解成小故事。
• 客户希望能按照类别浏览书籍，以便轻松找到自己喜欢的那一类书。
• 客户希望能够先把书放进购物车里，以便在之后某个时间购买。
• 亚马逊的产品经理希望能追踪客户的购买记录，以便有向客户推荐特定的书籍。
上述这 3 个用户故事都是非常明确和具体的，用户故事必须细化，能够对具体实践提供指导，但是不要预先制订落实方案。切记，工作如何执行必须由团队自行决定，至于成果该是什么，则取决于商业价值。如果把线上书店的所有因素都拼凑到一起，写成用户故事，那么这种用户故事常常可以合称为“长篇故事”，通常是很宽泛的，无法指导具体行动，但可以将其分解为多个具体的小故事。
当你开始写用户故事时，你就知道自己必须从某件事开始做起，写完用户故事，你会知道用什么来支撑自己的目标，接下来用户故事会指导你进行冲刺。
用户故事必须完整，任务必须彻底完成
在你撰写用户故事或列出待办事项清单时，有两个问题很重要：用户故事够完整吗？你如何才能知道自己已经完成了任务？
比如，我们看看一位朋友写的用户故事：“作为军队的医生，我必须为学生们传授基本的生理学知识，这样他们才能了解人体构造。”
关于一则用户故事是否完整，我经常用一套标准来衡量。一个好的用户故事应该满足以下标准：
独立性——尽可能让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制订计划、确定优先级和工作量评估都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
可协商性——用户故事的内容要是可以协商的，用户故事不是合同。一张用户故事卡片上只是一个简短的描述，不包括太多的细节。具体的细节在沟通阶段提出。如果一张用户故事卡片带有太多的细节，实际上会限制和用户的沟通。
有价值——每个用户故事必须对客户具有价值。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事，并不是一个契约，而且可以进行协商的时候，他们将非常乐意写下故事。
可评估——开发团队需要衡量用户故事，以便确定优先级和工作量，并便于安排工作计划。
规模小——一个好的故事要尽量维持小规模，至少要确保在一个冲刺周期中能够完成。用户故事越大，在安排计划、工作量评估等方面的风险就会越大。
可测试——一个用户故事要可以测试，以便确定它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。
这位朋友的的故事是独立的，因为他的学生们都在同一个城市，他不必考虑学生们在路程上的损耗，他能够独立完成任务。他的故事是可修改的，因为虽然他一开始打算为学生们传授基本的生理学知识，但如果他发现学生们已经具备这样的知识，或是已经有了一定的了解，那么他有其他的教学方法可以用。他的故事有价值：学生们学到人体知识之后，可以派得上用场。他的故事规模小：他只给学生们传授基本的解剖学知识，而不是教他们运用这些知识去开展外科手术。他的故事可测试：他很清楚自己想要传递的信息，也可以对学生开展一些小的测试，以便确认他们是否真的吸收了这些信息。
每个有待落实的用户故事都应该要有“完整”的定义。在现实中，我们发现，如果用户故事足够完整，那么团队在落实项目的过程中速度就会加快一倍。此外，如果一个阶段的冲刺完成了相应的用户故事，那么，这个团队的速度会再次加快一倍。这就是我们能够达到事半功倍之效的一个原因。