敏捷開發：Scrum 中的 Product Backlog 介紹

九卷發表於2024-11-20

敏捷Scrum

Product Backlog 產品待辦列表

在計劃開發產品功能時，都希望產品功能上線後，使用者能夠喜歡並經常使用。

因此在開發產品新功能時，就要衡量哪些產品需求是對使用者最有價值，這是最應該思考的問題。
然後把這些有價值的需求集合放在一起。當然，也有與需求實現相關的其它工作項。

在 Scrum 框架中，把產品待開發的功能集合放在一起就叫產品待辦列表（Product Backlog）。它是 Scrum 團隊實現產品目標所需完成的所有工作項的集合，是 Scrum 團隊進行工作規劃和執行的來源。它由產品負責人維護。

英文 backlog 意思是：大量堆積、積壓的事物或工作，也指“尚未完成的工作”，或“需要儘快處理的事情”。

在產品待辦列表中的工作項叫產品待辦事項（Product Backlog Item）。

如果待開發功能很多，那哪些功能優先開發？這就需要對產品待辦列表裡的功能集做一個優先順序排序，優先順序高的率先開發。

當然，隨著開發的持續進行，產品待辦列表中可能有不止功能性需求，還有非功能性特性。
比如：bug缺陷修復、基礎技術任務、比較大的使用者故事（Epic）、程式碼改進、架構最佳化、功能最佳化等等。

產品待辦列表特點

1、優先順序排序：產品待辦列表是一個按照優先順序從高到低進行排序的產品功能列表。它包含了產品有價值的需求、Bug修復、特性等列表項。
2、動態變化：產品待辦列表是一個動態變化的列表，隨著專案功能不斷開發，市場不斷變化，使用者持續的反饋，獲取的資訊和知識也越來越多，產品負責人可能會不斷的更新專案列表，新增新的需求或特性、調整優先順序、移除不再重要的功能等等。
產品待辦列表的持續更新和改進有助於團隊適應變化，並持續提供價值。
3、需求細節詳情：把將要在下一個迭代（Sprint Backlog）中完成的待辦項，描述時包含足夠的細節。比如使用者故事，大小合適並且符合 INVEST 原則，使用者故事三要素俱全，分解成故事點（用於估算工作量）。
4、透明性：產品待辦列表是 Scrum 團隊實現產品目標所需完成的所有工作項的集合，確保團隊成員都清楚產品要完成的工作項、方向和目標。團隊成員需要完成哪些工作都是來自這裡。
5、工作集：上面已經說明，產品待辦列表是 Scrum 團隊實現產品目標所需完成的所有工作項的集合。

產品待辦列表管理

產品待辦列表（Product Backlog）是由產品負責人（Product Owner）負責管理的。
隨著產品功能不斷開發，使用者持續反饋，市場不斷變化，獲取的知識增多，湧現新的想法，待辦列表裡的工作項會不斷進行改變和調整。待開發項（item）是隨使用者、市場不斷變化、持續演進的。

（from：https://www.visual-paradigm.com/cn/scrum/what-is-product-backlog-in-scrum/1000）

那怎麼管理變化，把這種變化反映到開發項中呢？那哪些又是不變的呢?

產品願景。這是不變的，它將作為指導產品待辦列表中工作項的建立、移除、修改。

變化的工作項，定期進行梳理，可以用 梳理會議 來進行管理。產品負責人可以透過定期舉辦梳理會議來梳理產品待辦列表。

梳理會議 的一些關鍵活動：

1、梳理產品願景。

2、建立、移除、調整產品待辦列表項。

3、拆分大的待辦項，比如 Epic（史詩）。產出合適大小的使用者故事。

4、澄清待辦項。

5、排列、修改優先順序排序。

6、利益相關者的溝通。

7、產品階段性目標。

8、待辦項的估算。

會議參與方：

產品負責人、Scrum Master、產品開發人員、業務部門人員（市場、銷售、業務、客服等）、產品經理、產品設計人員

為什麼會有這麼多人參與呢？

因為產品待辦項的內容來源，是由上述人員或部門提出的。他們會根據市場需求、使用者反饋、功能改進、技術重構等因素提出新的需求或改進點。

注意點，整理待辦項時需注意點：

這時候需求不需要事無鉅細，做到最基本的描述，力求簡潔。
可以使用者故事來描述需求，用卡片方式，前一節有講解。
低優先順序的需求條目可能數量大，而且是粗粒度。
非功能性需求，儘早描述詳情，因為可能對整個產品體驗產生很大影響。

使用者故事拆分方法

把比較大的故事比如 Epic，拆分成小的故事。使用者故事的一些拆分方法：

按照工作流程步驟拆分。要完成一個故事，需要哪些步驟，按照一個步驟一個步驟來進行拆分。
按照不同業務規則拆分。
按照操作來拆分。比如增加、刪除、管理等操作來進行拆分。
按照依賴先後順序拆分。比如一個故事開發依賴後一個故事，那麼這個後一個故事先開發。
按簡單/複雜進行拆分。比如先做簡單的故事，後做複雜的故事。

產品待辦列表優先順序評估介紹

產品待辦列表裡有很多待辦項，哪些待辦項首先做，哪些後面做？可以對待辦項進行優先順序評估然後排序。

對這些待辦項進行排序後，接下來，在衝刺（Sprint）計劃會議就可以安排哪些待辦項先進行開發。

優先順序評估的原則依據有哪些？

價值（使用者價值和商業價值）
成本
實現難度
風險大小
可釋出性

使用者價值、商業價值：

做產品，是解決使用者問題，給使用者帶來價值。需經常問自己：“做這個需求能給使用者解決什麼問題帶來什麼價值；不做呢？產品會有什麼損失，使用者會有什麼損失？”
當然，更希望產品給公司帶來商業價值。

成本：

估算實現的成本。比如人工成本，工作量大小，協同成本。

實現難度：

實現這個需求或特性，技術難度高不高。比如：實現此需求程式碼改動大；需進行技術預研；依賴其它需求的實現等等。
需求細化成更小故事後，可以用工作量來衡量。

風險大小：

做需求或特性，風險點有哪些，然後進行討論評估。比如說做創新產品，不確定性肯定高。

可釋出性：

對於產品功能，開發後的產品增量需要儘快釋出，更早得到使用者反饋。

優先順序評估方法或模型介紹

產品待辦列表的需求評估優先順序，可以採用多種方法，下面列舉一些常見評估方法。

KANO 模型

此模型透過客戶對功能滿意度來確定優先順序，將功能分為必備型需求、期望型需求、魅力型需求、無差異需求、反向型需求。

from： https://baike.baidu.com/item/KANO 模型/19907824

KANO模型需求分類：

必備型需求（屬性）（一定要有）：有的也譯作基本型需求（屬性）。使用者認為理所應當、必須要有的需求，這些需求必須被滿足。當這些需求不被滿足時，也就是不提供這些需求，使用者滿意度會大幅降低；當這些需求被滿足時，使用者滿意度不會得到提升。例如：手機打電話、發簡訊。
期望型需求（屬性）：滿足此需求時，使用者滿意度會提升；不滿足此需求時，使用者滿意度會降低。
魅力型需求（屬性）：使用者對這種需求沒有太大期望，需要產品經理對使用者有深刻的洞察才能挖掘到此隱性需求，屬於給使用者驚喜的需求。不滿足此需求，使用者滿意度不會降低；滿足此需求，使用者滿意度會急劇提升。有時是產品很有競爭力的體現。
無差異需求（屬性）：無論是否滿足此需求，對使用者滿意度都不會產生影響。
反向型需求（屬性）：有無此類需求，使用者根本不在意。若滿足此需求，使用者滿意度反而會下降。

它們的優先順序排序為：
必備型需求 > 期望型需求 > 魅力型需求 > 無差異需求

四象限法

四象限法是按照重要和緊急 2 個不同的緯度進行劃分，將需求放在二維或三維角度進行優先順序的決策。

按重要和緊急 2個維度，將需求任務劃分為【重要且緊急】、【重要不緊急】、【不重要但緊急】以及【不緊急不重要】四類。

需求任務分成四個象限：重要緊急 > 重要不緊急 > 不重要但緊急 > 不重要不緊急

重要緊急：重要緊急的需求任務，對產品影響很大，第一時間處理。
重要不緊急：這種型別的任務可以把它納入計劃，按計劃完成。
不重要但緊急：如果任務小花費時間少，可以馬上去執行完成。如果比較耗時，可以另外安排時間或交付給他人去做。
不重要不緊急：可以儘量不做。

注意點：

緊急不等於重要：緊急的任務，不等於重要的任務。比如當我們時刻關注使用者反饋，每天都有很多問題，這些有的是緊急但對產品影響不大的問題，在某個時間點完成就可以，對最終結果影響不大。

需求是變的：一般我們都是關注重要且緊急的任務，但是隨著需求的調整，其它型別的任務也會上升到重要且緊急的任務象限內。

RICE 框架

RICE 這個框架由 Intercom提出，旨在平衡成本和收益的系統，對需求進行評估。

RICE 框架是一種量化需求優先順序的模型，透過 4 個維度來給需求打分，然後算出最終得分。透過比較每個需求的得分來排定需求優先順序順序。

(from：intercom：rice-simple-prioritization-for-product-managers)

RICE 框架是由 4 個英文單詞的首字母組成，代表的意思分別是：

(R)each：觸達的廣度。需求覆蓋的使用者廣度，觸達的使用者數量或比例，在給定時間內影響多少產品使用者。可以透過埋點獲取指標、百度統計等系統來統計一段時間內的一些指標。

比如“每個季度影響多少客戶”。例如專案 1：每月有 500 名客戶到達註冊漏斗中的此點，其中 30% 選擇此選項。每季度覆蓋率為 500 × 30% × 3 = 450 名客戶

(I)mpact：影響的深度。需求對每個使用者影響的深度。比如 “當客戶使用該功能時，該功能將提高多少轉化率？20% 提高到了 27% 嗎？”。這個指標很難準確評估，這部分評估更加主觀一些。

Intercom 對這種主觀評估提供了一種評分方法，如下：

Intercom 用 3 - 0.25 的量表來評分：

3 表示 “影響力巨大”。

2 表示 “影響力高”。

1 表示 “影響力中等”。

0.5 表示 “影響力低”。

0.25 表示 “影響力最小”。

這些數字會乘以最終得分，以將其調高或調低。

(C)onfidence：對需求的信心。表示產品經理對該功能或需求的實現難度和成功率的信心，更多是產品經理對需求和使用者痛點的理解程度，對估算的信心水平，可以用百分比來表示。

Intercom 提供了一種量表來表示，如下：

用一個百分比量表來表示，避免決策困難

100% 表示 “高度信心”。如果有定量的資料支撐 Reach，定性的資料支撐 Impact，且開發評估了較準確的 Effort，那麼 Confidence 就是 100%。

80% 表示 “中等”。有定量的資料支撐 Reach，開發也評估了 Effort，但是 Impact 沒有資料支撐，那麼 Confidence 就是 80%

50% 表示 “低”。有資料支撐，但是資料的可信度較低，Effort 的波動也可能較大，那麼 Confidence 就是 50%.

低於這個數字就是 “完全不可能”。

請誠實地問自己：你的估計到底有多少信心支援？

(E)ffort：工作量。研發的成本，表示開發該功能或需求所需的工作量和資源投入，多個團隊合作的人，比如有市場、商務等，涉及團隊越多成本越高。工作量預估不確定因素較多。有一些方法：比如人天來估算；以故事點來估算。

Intercom 是用人月來估算-即是一名團隊成員一個月能完成的公工作。他堅持使用整數（或 0.5，用於一個月以下的工作），以保持粗略的估計。

Intercom 中關於 RICE 分數的計算：

Reach：這將影響多少人？（在規定的時間段內進行估算。）
Impact：這將對每個人產生多大影響？（巨大 = 3 倍，高 = 2 倍，中 = 1 倍，低 = 0.5 倍，最小 = 0.25 倍。）
Confidence：對需求成功的估算有多大信心？（高 = 100%，中 = 80%，低 = 50%。）
Effort：這將需要投入多少“人月”？（使用整數且最少半個月 - 不要陷入估算的泥潭。）