用户故事

（1）拆字理解，用户故事=用户+故事=人+故+事，通俗解释，就是什么人因什么原因做某事。提炼出来就是三个要素，who、why、what。用这3个要素组成最简单一句话的需求描述。

（2）用户故事（user story）是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：1. 角色：谁要使用这个功能。2. 活动：需要完成什么样的功能。3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

（3）用户故事准则包括：用户故事应保持独立；故事应独立于项目；故事应独立于事件；故事应独立于价值；故事应独立于用户期望。用户故事应保持独立 在用户故事里，角色往往是一个人，也可能是多个人，甚至是团队中的每个人。

（4）用户故事在软件开发过程中被作为描述需求的一种表达形式。为了规范用户故事的表达，便于沟通，用户故事通常的表达格式为：作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>。

（5）用户故事模板： 1. 谁？（作为___）：需求主人公，同一个需求对于不同的人会有不同的方式，在描述需求的时候要指明这是谁的需求。-作为大猩猩 2. 干了什么？（我想/我能___）：产品功能描述，一句话概括。

如何构建用户故事地图

1. 构建全景图，广度优先，而非深度，一公里宽一厘米深。尝试用故事地图描述所有内容，包括用户的痛苦和喜悦。探索。向深度拓展，讨论其他类型的用户，这些人又要做什么，哪些环节会出问题。

2. 方法：按照用户操作路径，将用户操作、评价、感受写上，得出用户情绪曲线。

3. 除了界面草图，用户画像、流程图、照片和文字描述都是不错的方案呈现方式，唯一重要的是（此处敲黑板），快速的、将它们呈现在所有人都可以轻易看到的地方。

4. 创建用户故事地图的8个步骤 1. 召集到3-5名对产品非常熟悉的人员参与。3-5人听上去像是个魔法数字，实际上是的。因为更少的人意味着你无法获得足够的建议，而更多人则会因为讨论和协调降低会议效率。

什么是用户故事?

拆字理解，用户故事=用户+故事=人+故+事，通俗解释，就是什么人因什么原因做某事。提炼出来就是三个要素，who、why、what。用这3个要素组成最简单一句话的需求描述。

概念这种东西我喜欢说文解字的方式去理解和阐述。用户故事=用户+故事=人+故+事，那就是一个人因为什么原因要做什么事，提炼出来三要素就是who、why、what。从需求角度描述就是一个用来确认用户和用户需求的简短描述。

用户故事（英语：User story）是指在软件开发和项目管理中用日常语言或商务用语写成的句子。User Story 是用户需求的简化表达，用一两句话表达完整的想法。

用户故事：从用户的角度来描述用户渴望被满足的需求，颗粒度级别最小，且能在一个迭代中开发完成。任务：需求是用户维度，任务是开发维度。需求是一个完整的用户故事，具有独立性的功能，可测试可交付。

需求 = User Story，用户故事是从用户角度来描述用户渴望得到的功能。 用户故事包括三个要素：角色：谁要使用这个功能；活动：需要完成什么样的功能；商业价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事的准则包括

敏捷项目计划:掌握敏捷项目计划的基本原则和方法,包括敏捷项目的愿望、用户故事、计算、优先级等。敏捷团队绩效:了解了如何创造高效的敏捷团队,包括建立立信任、沟通、决策等方面的能力。

接下来的1~2个Sprint中要完成的用户故事，需要足够的详细。而不着急开发的，则不必太详细。

在敏捷开发中,用户故事(user story)也是引导式研讨会的具体应用。 项目工作说明书(SOW) 是制定项目章程过程的输入,是对项目所需交付的产品、服务或成果的叙述说明。

       什么是AC？       AC全称Acceptance Criteria，又名“验收准则”，是敏捷测试中user story（用户故事）的重要组成部分。

拆字理解，用户故事=用户+故事=人+故+事，通俗解释，就是什么人因什么原因做某事。提炼出来就是三个要素，who、why、what。用这3个要素组成最简单一句话的需求描述。

用户故事1:什么是用户故事?

《1》拆字理解，用户故事=用户+故事=人+故+事，通俗解释，就是什么人因什么原因做某事。提炼出来就是三个要素，who、why、what。用这3个要素组成最简单一句话的需求描述。

《2》用户故事（user story）是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：1. 角色：谁要使用这个功能。2. 活动：需要完成什么样的功能。3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

《3》概念定义：用户故事是客户或业务部门与产品经理共同梳理需求时使用，用户故事也会被带入开发部门供开发做出功能。组成：编号，正文，开发估算。产品经理需要设计故事编号和正文内容，开发估算是开发评估出来的。

《4》用户故事（英语：User story）是指在软件开发和项目管理中用日常语言或商务用语写成的句子。User Story 是用户需求的简化表达，用一两句话表达完整的想法。

用户故事点和用户故事的区别

一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事带有了太多的细节，实际上限制了用户、团队的想法和沟通。

不同于预估时间，故事点关注的是复杂度，让所有人对同一个用户故事有相同的复杂度认知。

一个好的故事应该在工作量上短小，描述具有代表性，而且不超过3人天（或者3故事点）的工作量。超过这个范围的用户故事，将会在划分范围和估计时出现很多错误。

根据时间确定故事的规模。有些需求不一定要是故事，也可以就是一个任务。故事里需要包括用户；每个故事都只为一个用户编写。

使能故事和用户故事一样,通常是通过展示所获得的知识、制作的工件、或用户界面、打桩或模拟来展示。 好的故事需要多个视角的观点。