故事地图或单位积压？

Question

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

Answer 1

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

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

这些故事大部分都是“史诗”，因为有一个假设，即个别的Scrum团队会在晚些时候将它们分解成更小，更易于管理的故事。

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

在接下来的迭代中，我们计算出了时间估算值，并开始在每个团队的积压处放置它们的位置。这导致了一些关于故事的洗牌，但总的来说，最初的猜测是正确的。

在我们开始之后，由于两三次冲刺，“战争室”变得难以维持，所以我们在这一点上移回到一个Excel电子表格中，史诗依次列出。然而，那时产品所有者和客户已经内化了项目计划，所以没有必要维护它。

Answer 2

正如文章中所描述的那样，链接故事映射概念是改变对他们来说效果不佳的结果。所有球队都是不同的，你能做的最好的事情（在我看来）是选择一个你认为看起来很有希望的东西，并在下一次回顾中再次探讨它。进行调整，再尝试一些，再次回顾，等等。

Answer 3

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

Answer 4

托比亚斯在这里是另外两个关于故事映射的观点：John Walpole of Twitter shares their experience with story maps我也写过primer on story mapping。