身為產品經理，你是否也曾為用戶故事的積壓的問題苦惱過？本文作者介紹了一套體系方法，通過決定用戶故事的優先級來解決這個問題。

上個迭代還有好幾個用戶故事沒有完成！

燃盡圖沒有燃盡是因為出現了 Bug……

上述的吐槽聽起來是不是很熟悉？

我身邊的產品經理基本上都經歷過這樣的事情?？梢哉f，用戶故事的積壓和產品的缺陷對于產品經理們來說應該是家常便飯了。

深究其原因，我認為是大家缺乏一套體系的方法來決定用戶故事的優先級。

所以在這里，我想以自己的團隊為例，給大家介紹我們正在使用的排用戶故事和 Bug 修復優先級的工具框架。

一、為用戶故事排優先級

我的團隊采用了一套「故事排名系統」。

這套系統是這樣的：我們把緊急度和商業價值這兩個維度在 1 – 5 的范圍內取一個值，然后把這兩個數相乘以確定一個用戶故事的最終權重。

我們把權重標在一個矩陣上，用這種方法對產品路線圖中的用戶故事進行可視化和排列優先級。

在實際工作中，我會為每個用戶故事制作一張分值卡，上面有兩個打分項：緊急度和商業價值。

緊急度的取值與三個因素有關：交付時限、任務依賴和直接后果。

舉個栗子：一個緊急度為 1 的用戶故事可能沒有時間限制、影響很小，而一個緊急度為 5 的用戶故事可能時間緊迫并依賴很多其他用戶故事，如果不先把它完成就不能推進其他的故事。

商業價值的取值也與三個因素有關：客戶影響、品牌或聲譽影響和競爭優勢。

再舉個栗子：一個商業價值為 1 的用戶故事可能只對很少的客戶／用戶有影響，而一個商業價值為 5 的用戶故事則對每個客戶都很重要——也對公司生存很重要。

怎樣確定每個用戶故事的分值呢？可以使用緊急度排序表來確定。

說了這么多，我們給每個用戶故事分配了緊急度和商業價值這兩項的數值之后，怎么決定用戶故事的輕重緩急呢？

你要做的，就是把每個用戶故事放入這個矩陣。在實際使用中，我發現老板和公司更喜歡晚一點再對付取值 6、8、9 的用戶故事，所以我根據實際情況「修訂」了一下矩陣。

二、為產品 Bug 排優先級

在我的團隊推廣了用戶故事優先級這套方法之后，我們把主要精力放在了對付產品 Bug 上面。

有一天我靈機一動：能不能用同樣的方法對付 Bug 呢？當然可以，只不過矩陣上的橫縱軸要改一下：橫軸從緊急度變成影響范圍，縱軸從商業價值變成嚴重性。

每個 Bug 仍然分配從 1 到 5 分配一個取值，然后把這兩個數相乘以確定一個 Bug 的最終權重。

與用戶故事類似，我也為每個 Bug 制作了一張分值卡。

與上文中的用戶故事一樣，這里也要說明一下 Bug 的兩個打分項：

Bug 的影響范圍與受影響的用戶數和產品功能相關。舉例：影響范圍為 1 的 Bug 只牽涉少數用戶或產品功能，而影響范圍為 5 的大 Bug 則會波及所有用戶和大多數產品功能。

Bug 的嚴重性取決于解決它的難易程度。再舉例：嚴重性為 1 的 Bug 可以代表錯別字或者美工問題，但嚴重性為 5 的 Bug 可能意味著損壞或丟失數據，或者讓產品完全不能用。

我們得到了這樣一個 Bug 優先級矩陣，并根據實際需要做了微調：

一點心得

我的團隊通過使用這兩種優先級工具，居然能夠有條不紊地順著 Bug 列表來開展工作，這在以前是不可想象的。

通過這兩種工具，我們不僅產品質量有了提升、而且流程精簡了許多。

通常我們會先把想法扔進 Aha!，然后再把用戶故事或 Bug 放入矩陣排列優先級。像這樣：

不知大家對這種排產品列表優先級的方法有什么看法？又或者，各位在自己的團隊里平日有什么好的做法？歡迎在評論區里共同交流進步~

編譯自：https://tpgblog.com/2017/10/16/how-to-quickly-prioritize-your-product-backlog/

原作者：Christopher Davis

作者：「即能小程序」，公眾號：「即能學習」

本文由 @即能 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自?Unsplash，基于 CC0 協議