project-management - 故事地图还是平面积压？

Question

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

Answer 1

与 Scrum 一样，做你认为需要的最少的事情。太多的文档可能会变得无法维护，只会让您束手无策。

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

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

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

在接下来的迭代中，我们计算出时间估计，并开始在每个团队的待办事项中列出它们的位置。这导致了一些故事的改组，但总的来说，最初的猜测是正确的。

在我们开始“作战室”之后的两到三个冲刺变得更难维护，所以我们在那个时候转移回了一个 Excel 电子表格，其中按顺序列出了史诗。但是，到那时，产品所有者和客户已经将项目计划内化了，因此没有必要对其进行维护。

Answer 2

这里的 Tobias 是关于故事映射的另外两个观点：Twitter 的 John Walpole 分享了他们在故事映射方面的经验，我还写了一篇关于故事映射的入门书。

Answer 3

如文章中所述，您将 Story Mapping 概念联系起来是因为更改了一些对他们来说效果不佳的东西。所有的团队都是不同的，你能做的最好的事情（在我看来）就是选择一个你（团队）认为看起来很有希望的事情，然后尝试进行冲刺，并在下一次回顾时再次讨论它。做出调整，多尝试一些，然后在回顾中重新审视，依此类推。

Answer 4

故事地图是一种很好的计划技术，但我不会使用故事地图本身来进行跟踪。我会使用地图上标识的功能/场景作为功能桶，我会使用停车场图表来显示每个功能的进度。这里的一个好主意是确定交付每个功能所需的最少功能（当然，这些应该是该功能的最高优先级故事），并在停车场图表上为每个功能画一条线，显示何时该最少功能已实施。这是一种向外部利益相关者准确展示产品所在位置的清晰方式。