故事地圖或單位積壓？

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。