UserStoryMapping是JeffPatton提倡的一种技术。它为我们提供了一种将整个产品或服务设想为用户完成的一系列任务的方法。从纯粹的实用意义上讲，它涉及构建一个用户故事网格，这些用户故事排列在代表用户对产品的体验的标题下。这可以通过团队成员之间的一系列对话来迭代完成。因此，第一次尝试可能看起来像这样，用户故事按各自的功能分组（有些人可能将这些顶级功能称为“史诗”）。在这里，我们将产品的高级功能（骨干，如果你愿意的话）分解为组件用户故事。很容易看出每个用户故事属于哪个功能，因此每个用户故事都在整个产品的上下文中呈现，而不仅仅是列表中的一个项目。虽然这种方法有助于组织我们的想法——它已经比简单的故事列表提供更多信息——但它实际上还没有构成故事地图，因为它没有考虑用户旅程的流程。开发故事地图让我们通过想象一个简单的电子商务网站来使我们的示例更加具体。产品愿景板提到了三个功能：产品页面产品搜索查看初始故事地图可能是什么样子：我们有一个“产品页面”功能，其中包含与下面列出的功能相关的用户故事，也适用于产品搜索和结帐功能。但是故事的发展不是特别好，也没有迹象表明每个故事有多重要。例如，要求用户在订购前阅读产品说明，但这是在阅读评论之前还是之后发生的？哪个能为用户提供更多价值？在进行更多研究并收集利益相关者的更多意见后，另一个迭代可能看起来像这样。请注意，我们通过将其中一些细分为更小的部分来改进我们的用户故事，我们引入了一个新的维度，故事按用户旅程中的位置排列，我们已经开始在我们的地图顶部附近安排最高优先故事朝这个方向走得更远，很容易看出我们是如何最终得到一张地图，上面列出了前几个补丁中需要包含哪些故事。构建故事地图（VisualParadigm）故事地图是用于需求收集的4级层次结构。故事地图以从不同来源（即积压）收集的用户特征集合开始，这些特征将通过执行某些任务作为活动来完成。这些任务可以转化为史诗，然后转化为软件开发的用户故事。StoryMap结构：用户实现目标的能力（博客记录）>Activities>Tasks>Epics>StoryMap的StoryPlanning步骤为了促进敏捷开发，StoryMap可以接收从不同来源识别的用户特征。如上所述，它可能是来自EA合同的需求、工作包或来自项目管理计划的特殊分析（例如-是和未来分析）、使用图表中的用例与敏捷软件开发的集成等。假设我们已经积累了一个列表来自几个不同来源的故事地图积压中的用户特征。用户功能通过执行某些任务作为活动来实现。每个任务都可以进一步分解成几个史诗（更大的用户故事）。每个史诗都包含一个用户故事列表，这些用户故事被分解为适合冲刺迭代的大小。以下是规划故事地图所涉及的步骤：从左到右将用户特征拖动到地图的顶行。地图顶行中的每个功能都是呼叫用户活动。创建完成一项活动所需的步骤数，称为用户任务。这些用户任务中的每一个都可以分解为多个史诗。在史诗下，可以定义用户故事列表，调整大小以适应冲刺。注意：我们可以考虑从左到右排列实现的优先级，从上到下排列用户故事的优先级。相关链接敏捷用户故事映射工具有效的用户故事工具
