Product Backlog所面臨的問題
1. Product Backlog的來源有很多個
一般來說，資料的來源有以下幾類：
(1) 產品功能：在這一次版本中需要實作的功能。
(2) Bug：上一版或是上一個循環(iteration)所遺留下來的問題，需要在這一版處理。或者是對客戶端有嚴重的影響，要求緊急處理的問題。
(3) 技術上的負債(Technical Debt)：有關於技術上的問題，例如執行速度太慢、無法容易擴充、使用介面不好操作、或者不方便日後維護等等。不算是bug，但是若是能修改，會對專案日後有很大幫助。(有些客戶會認為速度太慢，其實也算是bug)
多個需求來源，會造成專案上管理的複雜度，因為你會不知道那個比較重要，或者哪個比較緊急。到底要聽誰的，你很難下決定。
比較好的作法，是將不同需求，經過適當的檢視，然後把他們放到同一個Product Backlog。這樣你才能統一管理，並且會只有一個優先順序，不用再煩惱到底要做哪一個。
2. Product Backlog的內容沒有優先順序
雖然把多個來源的需求，放到同一個Backlog中，似乎是可以排出優先順序，可是你可能會問一個問題：這些來源都是不同性質的東西，要如何比較呢？產品功能、Bug、和技術上的負債看起來是多不相同的東西，要怎樣來衡量是比較公平的呢？
不管他們的來源為何，但是記得一件事情，我們所作的事情都是為了提供客戶更高的價值，因此我們可以從商業價值的角度來評比，到底誰的價值比較高，誰的優先順序就比較前面。
因此你必須先把他們轉換成user story的形式，再來比較他們之間的商業價值，以做出最後的優先順序列表。
當你以user story的方式表達他們的商業價值後，你要怎麼決定他們的優先順序呢？
最常用的方法是投票表決，來決定這個項目是否很重要。認為很重要的就舉手，不重要就不舉手的，然後藉由票數的多寡來。這一種很快的方式來找出答案，
不過它有一個很大的缺點，那就是舉手不舉手是一種0與1的抉擇。可是世界上不會只有黑與白，或是藍與綠。你可以中間偏綠，或者中間偏左，選擇是多元的。
因此另一種折衷的方式，就是你可以用手指頭的個數，來表達你對這件事情的認同程度。只要你先講好越多代表越贊同，或者是代表越不贊同。之後便請大家利用手指頭個數，來表決每個項目的優先順序。
來源：http://leadinganswers.typepad.com/leading_answers/2007/02/team_decision_m.html
留言列表
