Project management 故事图还是平面积压？

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

正如您链接的文章中所述，故事图概念是由于更改了一些不适合他们的内容而产生的。所有的团队都是不同的，在我看来，你能做的最好的事情就是选择一件你（团队）认为很有希望的事情，然后尝试一次冲刺，并在下次回顾时再次讨论。进行调整，然后再试一次，再次访问retrospect，以此类推。

与Scrum一样，尽可能少做您认为需要的事情。太多的文档可能无法维护，只会束缚您的手脚

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

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

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

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

---

在我们开始“战争室”后的两到三次冲刺中，维护变得更加困难，因此我们回到了Excel电子表格中，按顺序列出了史诗。然而，到那时，产品所有者和客户已经将项目计划内部化了，因此不需要维护它。

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

Tobias这里有两个关于故事映射的其他观点：我还写了一篇。

真的。在我们开始尝试这个概念之前，我希望从其他人那里得到一些反馈。我投票结束这个问题，因为它与编程无关。