故事地图或平面积压？

Question

我努力为我的scrum项目创建良好的可视化/跟踪，因此正在考虑几种替代方案。一个有趣的概念是Story Mapping。您对使用故事地图而不是平坦的积压有任何意见吗？

Answer 1

与Scrum一样，至少做你认为需要的事情。太多的文档可能无法维护，只会让你失望。

那就是说：在之前我们有大约15个Scrum团队的角色中，我们有一个“战争室”，故事被映射到一个墙壁大小的白板上。

这些故事中的大多数都是“史诗”，因为有人假设个别Scrum团队稍后会将它们分解为更小，更易于管理的故事。

最初，没有时间估计与这些史诗相关联，因为地图的目标是识别史诗之间的依赖关系，并大致了解哪个团队最适合做哪个史诗。

在接下来的迭代中，我们计算了时间估算值，并开始在每个团队的积压工作中占据一席之地。这导致了一些故事的混乱，但总的来说，最初的猜测是正确的。

在我们开始“战争室”之后，通过两到三次冲刺变得更难维持，所以我们在那时转回到Excel电子表格，顺序列出了史诗。但是，到那时，产品所有者和客户已将项目计划内部化，因此无需维护。

Answer 2

Tobias在这里是另外两个关于故事映射的观点：John Walpole of Twitter shares their experience with story maps我还写了primer on story mapping。

Answer 3

正如你在文章中所描述的那样，故事映射概念是改变一些不适合他们的东西的结果。所有球队都是不同的，你能做的最好的事情（在我看来）是选择一个你（球队）认为看起来很有前途的东西并试着冲刺并在下一次回顾中再次谈论它。进行调整，再尝试一下，再回顾一下，等等。

Answer 4

故事映射是一种很好的规划技术，但我不会将故事地图本身用于跟踪。我会使用地图上标识的功能/场景作为功能桶，我会使用停车场图表来显示每个功能的进度。这里的一个好主意是确定运送每个功能所需的最小功能（当然这些功能应该是该功能的最高优先级故事），并在停车场图表上为每个功能添加一行，以显示何时功能最少的功能已实施。这是向外部利益相关者准确显示产品的明确方式。