用户故事与示例和模板
用户故事是开发任务，通常表示为“角色 + 需求 + 目的”。
开始使用冲刺待办事项模板
借助功能强大的待办事项模板优化冲刺规划，实现任务有序整理、角色清晰界定，并提升团队协作效率。
简而言之，人们往往认为用户故事是软件系统要求。但其实不是。
敏捷软件开发的一个关键组件是以人为本，而用户故事则将最终用户置于对话的中心。这些故事使用非技术性语言为开发团队及其工作提供背景信息。
阅读用户故事后，团队能够知道他们为什么要构建、他们在构建什么，以及这能创造什么价值。用户故事是敏捷项目群的核心组成部分。它们提供了以用户为中心的日常工作框架，进而促进协作、激发创造力，最终打造出更优质的产品。
什么是敏捷用户故事？
正是这项关于用户故事的工作帮助 Scrum 团队更好地掌握估算与冲刺规划技能，进而实现更精准的预测和更高的敏捷性。借助故事，看板团队可以了解如何管理进行中的工作 (WIP)，并且进一步完善其工作流。
用户故事也是更大规模敏捷框架的基础组件，例如长篇故事和举措。长篇故事是可拆解为一组用户故事的大型工作项，而多个长篇故事则构成一项举措。
这些更大的结构确保了开发团队（负责用户故事）的日常工作能够助力融入长篇故事与举措中的组织目标达成。您可以点击此处了解有关长篇故事与举措的更多信息！
为什么要创建用户故事？
对于刚接触敏捷的开发团队来说，用户故事有时看起来像一个额外的步骤。为什么不把大项目（长篇故事）分成一系列步骤，然后继续下去呢？故事为团队提供重要的背景信息，并将任务与它们创造的价值联系起来。
用户故事有许多关键益处：
故事聚焦于用户。待办事项列表可以让团队专注于需要核对的任务，而故事集则使团队专注于为真实用户解决问题。
故事促成协作。在确定最终目标后，团队可以共同决定如何为用户提供最好的服务并实现这个目标。
故事推动创造性解决方案。故事鼓励团队以批判性和创造性的方式思考如何通过最佳的方案来实现最终目标。
故事创造动力。随着每一故事的演绎，开发团队都会享受一个小挑战和一次小胜利，促进了前进动力。
使用用户故事
故事写完后，应该整合到您的工作流中。故事通常由产品负责人、产品经理或项目群经理撰写并提交审核。
在冲刺或迭代计划会议期间，团队将决定他们要处理这次冲刺的哪些故事。团队现在讨论每个用户故事所需的要求和功能。这是团队在实施故事当中获得技术和创造力的机会。一旦取得共识，这些要求就会添加到故事中。
在这样的会议中，另一个常见步骤是根据故事的复杂性或完成时间对故事进行评分。团队使用 T 恤尺码、斐波那契数列或 Planning Poker 来做出正确估计。故事篇幅应调整为可在一次冲刺中完成。因此，团队在确定每个故事的规格时，要确保将超过完成期限的故事拆分开来。
如何撰写用户故事
在撰写用户故事时，请考虑以下几项：
“完成”的定义 - 一般来说，当用户可以完成概述的任务时，就表示故事已经“完成”，但一定要明确它的具体含义。
概述子任务或任务 - 确定需要完成的具体步骤，以及每个步骤的负责人。
用户角色 - 为谁而做？如果有多个最终用户，可以考虑创建多个故事。
有序的步骤 - 为更大流程中的每个步骤撰写一个故事。
听取反馈 - 与您的用户交流，用他们的语言来捕捉问题或需求。倘若能从客户那里获得故事，您便无需再对故事做猜测。
时间 - 时间是一个敏感的话题。许多开发团队完全避免讨论时间，而是依赖于自己的估算框架。由于故事应能在一个冲刺阶段完成，因此应将可能需要数周或数月才能完成的故事分解成更小的故事，或将其视为自己的长篇故事。
明确定义用户故事后，确保它们能为整个团队所见。
用户故事模板和示例
用户故事通常用一个简单句子来表述，其结构如下：
“作为 [角色]，我 [想要]，[从而]。”
分解一下：
“作为 [角色]”：我们在为谁构建这个？我们追求的不是职位，而是这个人的角色。譬如，Max。我们团队应该对 Max 是谁有共同的理解。我们应该已经采访许多的 Max。我们了解这种人的工作方式，以及他们的想法和感受。我们对 Max 感同身受。
“想要”：这里我们描述的是意图，而不是所用的功能。究竟想要实现什么目标？这句陈述应该不涉及具体实施。如果您描述的是用户界面的任何部分，而不是用户目标，那么您就不得要领了。
“从而”：想要即刻做某事的愿望如何与大局保持一致？试图实现什么样的总体效益？需要解决什么样的大问题？
例如，用户故事可以这样表述：
作为 Max，我想邀请我的朋友，从而能一起享用这项服务。
作为 Sascha，我想组织自己的工作，从而能感受到更大的掌控力。
作为一名经理，我想要了解同事的进展，从而能更好地报告我们的成功和失败。
此结构不是必需的，但它有助于对“完成”进行定义。当这个人物能够得到想要的价值时，故事就完成了。我们鼓励团队定义自己的结构，然后坚持下去。
敏捷用户故事入门
用户故事描述开发团队成员日常工作的背景和原因，通常表述为角色 + 需求 + 目的。了解他们的角色，作为团队所交付内容和原因的事实来源，是顺利完成一个流程的关键。
首先评估下一个或迫在眉睫的大型项目（例如长篇故事）。将其分解为几个较小的用户故事，并通过与开发团队合作来加以提炼。一旦您的故事公布出来，让整个团队都能看到，您便准备好上马项目了。