Scrum 是什麼（4）：Product Backlog

January 03 08:46~10:35

前情題要：

• 〈Scrum 是什麼（1）：雙重回饋機制〉
• 〈Scrum 是什麼（2）：Scrum 的內涵〉
• 〈Scrum 是什麼（3）：三種補充文件〉

***

前幾集介紹了 Scrum 雙回饋機制與 Scrum 的內涵，包含角色、產出物與活動，這一集依照順序應該要提到當鄉民們要在專案中開始採用 Scrum 時，要如何開始第一個 sprint。不過 Teddy 之前已經先偷跑談過這個問題了，請參考「萬事起頭難：如何開始第一個 Sprint？」與「Iteration 0 要幹麼？」，所以本集 Teddy 就來談一下 product Backlog。

先幫鄉民們複習一下 product backlog：

所有關於此專案或是產品的 stories 就稱為 product backlog，放在 product backlog 裡面的項目（稱為PBI，Product Backlog Item）要經過「排序」，比較重要，比較優先要施工的項目放在前面。鄉民們可以直接用 excel 來紀錄 product backlog，當然也可以用支援 Scrum 的軟體系統（例如免費的 ezScrum）甚至是一般的文字檔來管理 product backlog。

3 年多前 Teddy 開始採用 Scrum 的時候，從網路上面下載了一個 excel 檔案可以用來管理 product backlog。由於時間久遠當初下載的連結 Teddy 老早就忘了，Teddy 把這個檔案放到 Dropbox 的 public folder 如果鄉民需要的可以從「這裡下載」。

把這個 ProductBacklog.xls 檔案打開之後，切換到 Backlog 這個頁面，會看到這個 product backlog 目前有三個 stories。這算是一個典型的 product backlog 格式，Teddy 稍微解釋一下每一個欄位的意義。

• ID：流水號，沒什麼特別的意義。
• Imp：重要性（importance）是一個整數值，用來排序 stories 之用。基本上越重要的 stories 會先被選出來施工。這個重要性的數值其實只是用來排列 story 的順序（order）之用，把不同 story 的重要性拿來比較是沒有意義的。例如，一個重要性為 80 的 story 並不表示它比一個重要性為 40 的 story 還要「重要兩倍」。這個觀念有時候對於剛開始採用 Scrum 的團隊會造成混淆而經常卡在如何設定重要性上面（這個重要性只能由 Product Owner 來決定）。為了避免混淆，後來新版的 Scrum 好像把這個欄位改稱做 Order（Teddy 還沒有時間去仔細研究一下改版後的 Scrum...XD）。Teddy 自己的作法是，如果最近 2-4 個 sprints 內可能施工的 stories，就把他們的重要性設在 99 - 70 這個範圍之內，如果是 2-4 個 sprints 之後但是半年之內可能會施工的 stories，則全部設定為 60。其他剩下的 stories 可能是還沒想清楚的需求（很模糊的需求與概念），或是一些閒雜人等對於軟體的「幻想 願望」，那麼重要性就全部都設成 40。反正每一個 sprint 還有一個 product backlog refinement meeting 可以去持續調整 product backlog 的內容。當然，平常 Product Owner 閒閒沒事的時候也要經常去耕耘 product backlog，畢竟整個產品（軟體）開發的方向（需求順序）都要依靠 product backlog 來決定啊。
• Name：Story 的名字。不過這個 ProductBacklog.xls 檔案裡面的例子寫得不好，story name 應該就是一個句子，類似 As a user, I can do something so that I can achieve xxx（身為使用者，我可以做某件事情以達成某項目標）。
• Notes：備註欄位，由於 story name 只是一個簡短的句子，在備註欄位中可以註明其他需求項目作為 sprint planning meeting 時與團隊成員討論需求時的「小抄」（提醒之用）。
• How to test (How to demo)：該 story 的驗收條件，有的人把這個欄位寫成 how to test 也有人寫成 how to demo。這個欄位滿重要的，因為有了這個欄位開發人員才知道說這個 story 的「最小完工要求「」，而與測試人員（如果很幸運的團隊裡面有這樣的人力配置的話...XD）也才知道要如何驗收這個 story （最小驗收條件）。最後，sprint demo meeting 時就依照這個欄位所敘述的方式來展示每一個完成的 story。
• Estimate：Story point 的估計值。關於估算 story point 的問題請參考「如何估算 story point？」與「Story point 為何沒有單位：相對論篇」。

***

打好 stories 之後，每個 sprint planning meeting 時，就可以把該 sprint 預計施工的 stories 印出來。這個 ProductBacklog.xls 檔案裡面有 Excel 巨集程式，可以產生如下圖所示的 story cards。一張 A4 紙剛好可以列印兩個 stories，再用刀片割開就 OK 了，還算滿方便的。

***

接下來 Teddy 分享一下管理 product backlog 的經驗，三年半前 Teddy 剛開始採用 Scrum 的時候，一開始是把全部的 stories 都打到 excel 檔案中，用這個 excel 檔案來管理 product backlog 。但是，不知道是 Teddy 真的不太會用 excel 還是怎樣，隨著一個 sprint 一個 sprint 過去，用這個 excel 檔案來管理 product backlog 就變得不太方便，為什麼呢？

 

假設 sprint 1 的時候鄉民們的 product backlog 裡面有 100 個 stories，當 sprint 1 結束之後完成 5個 stories，那麼這 5 個完成的的 stories 就從 product backlog 移除。但是你又會想要把這些已經完成的 stories 找個地方存起來（總不能做完之後就砍掉吧），此時 ProductBacklog.xls 這個檔案的設計就顯得有點不太方便。當然如果鄉民們的 excel 功力高強可以幫 ProductBacklog.xls 的 Backlog 頁面的每一個 story 加上「狀態」這個欄位，這也是一種方法。

 

總之到後來 Teddy 是直接把 stories 都打在一個文字檔（老狗學不了新把戲...Orz），然後每個 sprint planning meeting  之前 Teddy 再把這個 sprint 要施工的每一個 stories 複製到 ProductBacklog.xls 的 Cards 頁面中。換句話說就是只利用 ProductBacklog.xls 來印出 story cards 而已。

 

下一集：〈Scrum 是什麼（5）：初探 Sprint Planning Meeting〉

***

友藏內心獨白：Product backlog 裡面的 stories 要如何生出來啊？