故事映射是Jeff Patton倡导的一项技术。它为我们提供了一种将整个产品或服务设想为用户完成的一系列任务的方法。

从纯粹的实际角度来说，它涉及构建一个用户故事地图，这些故事在标题下排列，代表用户在产品中的体验。这可以通过团队成员之间的一系列对话迭代完成。因此，第一次尝试可能看起来像这样，用户故事按其各自的功能分组（有些可能称这些顶级功能’Epics’）。

用户故事映射

在这里，我们将产品的高级功能（骨干，如果您愿意）分解为组件用户故事。很容易看出每个用户故事属于哪个功能，因此每个用户故事都在整个产品的上下文中呈现，而不仅仅是列表中的项目。

虽然这种方法有助于组织我们的想法 - 它已经比简单的故事列表更具信息性 - 它实际上还没有构成故事地图，因为它没有考虑用户旅程的流程。

开发故事地图

让我们通过想象一个简单的电子商务网站让我们的例子更加具体，产品愿景板提到了三个特征：

最初的故事地图可能如下所示：

一个简单的用户故事地图

我们有“产品页面”功能，其中包含与下面列出的功能相关的用户故事，同样适用于“产品搜索”和“结帐”功能。但是这些故事还没有特别好地发展，并且没有迹象表明每个故事的重要性。

例如，用户需要在订购之前阅读产品说明，但这是在他们阅读评论之前或之后发生的吗？哪个为用户提供更多价值？

在进行了更多的研究并收集了来自利益相关者的更多意见之后，另一次迭代可能看起来像这样。

考虑用户旅程的用户故事地图

请注意，我们通过将其中的一些细分为较小的部分来改进我们的用户故事，我们引入了一个新的维度，故事按照用户旅程中的位置排列，我们已经开始安排最高的我们地图顶部附近的优先故事

在这个方向上进一步发展，很容易看出我们最终是如何得出一张地图，指出在前几个版本中需要包含哪些故事。

用户故事地图，指示发布

故事映射作为迭代过程

所有这些细节都来自团队成员和利益相关者之间关于如何最好地尽早为用户和业务提供最大价值的对话。故事地图为该对话提供了一个框架，一种在对话过程中直观地表达想法的方式，以及一种记录结果的方式，与平面产品积压不同，它可以捕获用户旅程的所有背景。

故事地图与产品本身一样，始终是一项正在进行中的工作。它为我们提供了当时团队思维的快照。随着我们继续与用户和利益相关者进行讨论，随着收集的更多证据证实或使我们的假设无效，故事地图可以相应地改变和发展。

通过按功能对用户故事进行分组，故事地图可确保我们创建有意义的版本，允许用户完成端到端的旅程。它帮助我们构建了第一个版本，它是最不可行的产品，然后对其进行迭代，为每个新版本的业务和用户带来新的价值。

通过Jeff Patton和其他人的努力，用户故事地图正在成为一种流行的用户故事管理技术。用户故事工具允许您通过用户活动，用户任务，史诗和用户故事的细分来为待办事项建立多个级别和维度。通常，敏捷开发团队在协作会议中使用故事地图来识别最终用户想要实现的期望结果。

用户故事地图

使用故事地图作为用户故事工具的好处很少：

Visual Paradigm使故事地图功能在桌面应用程序和云用户故事工具中都可用。它代表了客户对产品进行的旅程，包括用户活动（也称为主干）的识别以及实现活动的一组相关任务。用户通过拖放用户界面基于用户活动和相关任务来组织积压的工作。

故事地图是一个用于需求收集的4级层次结构。故事地图从不同来源（即积压）收集的用户特征集合开始，这些用户特征将通过执行某些任务作为活动来实现。这些任务可以转换为史诗，然后转换为软件开发的用户故事。

故事地图结构：用于实现目标的用户功能（待办事项记录）>活动>任务>史诗>故事

用户故事地图的结构

为了促进敏捷开发，Story Map可以接收从不同来源识别的用户功能。如上所述，它可能是来自EA合同的要求，来自项目管理计划的工作包或特殊分析（例如 - 是和将来的分析），使用图中的用例与敏捷软件开发集成等等。

将用例发送到Backlog

假设我们已经从多个不同的来源累积了故事地图积压中的用户特征列表。通过执行某些任务，将实现用户功能作为活动。每个任务都可以进一步分解为几个史诗（更大的用户故事）。每个史诗都包含一个用户故事列表，这些用户故事被分解为适合适合sprint迭代的大小。以下是规划故事地图所涉及的步骤：

请注意：我们可以考虑从左到右安排实施的优先级，从上到下安排用户故事。