产品待办列表梳理(PBR)是什么？
產品待辦列表(PBL)是Scrum框架下最重要的一個工件(Artifact)，產品待辦列表的梳理(Product backlog Refinement-PBR)也是一個重要的活動，它不同于Scrum的3-3-5-5。仔細閱讀Scrum指南，對產品待辦列表梳理活動的描述是有限的：
“只有那些Scrum團隊可以在一個Sprint中完成的產品待辦事項，才能作為Sprint計劃會議中的準備就緒事項。這種透明度通常需要通過“產品待辦列表梳理”活動來獲得。產品待辦列表梳理是將產品待辦事項進行拆分，并進一步梳理為更小更精確的事項。這是一項持續不斷的活動，用來為產品待辦事項補充細節，包括細節描述，排序和評估大小等。添加的細節屬性通常隨工作領域的不同而變化。”
在CSM的培訓中，我發現有時學員把PBR活動與Sprint計劃會議混為一談，在Sprint計劃會議上做產品待辦列表梳理。有時把產品待辦列表的梳理說成是Sprint Backlog的梳理。借機來寫一篇文章，“梳理”一下產品待辦列表梳理活動的概念。結合多年教學咨詢的經驗，與國際敏捷專家在敏捷社區的切磋，分享我理解的PBR的具體做法和常見誤區，對Scrum指南的PBR部分也是一個補充和解讀。
1. 為什么要做產品待辦列表梳理PBR？（why）
我們承認對于敏捷項目或產品，需求是一個漸進明細的過程，過早的鎖定范圍和細化需求是不明智的。所以，需求的梳理是一個持續的活動，一個just in time的規劃過程。即每個迭代的過程中，開發團隊除了圍繞Sprint的目標，按照Sprint Backlog(SBL)的計劃盡力實現承諾的產品待辦條目(Product backlog Item - PBI)之外，還要抽出一部分時間來協助PO梳理需求，確保下一個迭代計劃會議的需求是就緒的(ready)。這樣做的目的，增加了Sprint計劃會議團隊承諾的信心指數，大大降低了交付的風險。
那么問題來了，準備多少個PBI和PBI梳理到什么程度算是比較合適呢？一般情況下，我們建議準備1-2個Sprint的需求，最多不要超過3個Sprint的內容, 采取剛剛好(just enough)的策略。試想一下，只準備一個迭代的需求可能不夠，另外PBL的優先級可能會發生變化，所以稍微多準備一些。但梳理太多會造成不必要的浪費， 因為情況總是在發生變化。產品待辦列表的梳理活動上，團隊不會承諾下一個Sprint做多少。
有什么樣的原則能夠指導PBL梳理就緒？
產品待辦列表PBL滿足“DEEP”的特征。通常我們用DEEP來體檢PBL的健康狀態。
D: 需求的顆粒度有不同的層級，優先級高的需求細化。
E: 估算PBI的成本大小。
E:?擁抱需求變化，新的涌現出來的需求，以PBI的形式添加在PBL中。?
P: 排優先級，即排序。
對于PBI的就緒，主要滿足大家熟悉的INVEST的原則(見下圖對INVEST的解釋)，Scrum的模式語言Definition of Ready(DoR)對我們的實踐指導是有效的，盡管DoR不是Scrum的核心內容，但會幫助我們理解PBR活動的重要性。定義DoR的維度，除了INVEST以外，還考慮：提前識別技術難點(spike)；依賴關系；UI/UX的設計工作；合規和法律認證的事宜。一個DoR的例子如下：
2.?PBR活動包括什么具體內容（what）
主要包括：
-
對PBI的業務價值和驗收標準的澄清，討論足夠的細節，包括新近加入PBL的優先級高的需求條目。
-
大的需求(Epic)的拆分(breakdown)，注意是對PBI的拆分，不是傳統的任務分解(WBS)。如果PBI的優先級很高，要拆到這個PBI能夠fit到Sprint中，不同PBI拆分有不同的策略，這里不再敘述。
-
估算，有時也叫Sizing，總之是估PBI的effort。敏捷推薦相對估算。建議對所有的PBI都要給出估算(如果可能的話)，注意這里不是指SBL的條目SBI，任務的估算。?
-
對PBL的重新排優先級，PO會按自己的價值方法對PBL的排序，在PBR活動中，開發團隊協助PO審視PBL優先級的合理性，比如涉及PBI之間的技術依賴或資源約束條件等，重新排優先級。
-
另一個最重要的動作，看看哪些需求沒有價值，不合理，從PBL刪除，保證PBL的健康度(good shape)，有時用鄧巴數(150定律)作為參考PBI的個數。
Scrum框架中設計的持續進行的產品待辦列表梳理活動(PBR)是一個落地的“對話”實踐。研發和業務人員以對話為核心，采用不同的技術和工具，補充豐富并完善細化PBL。敏捷團隊的具體實踐有：交互式原型(UI prototype)，線框圖，視覺模型，流程圖(flow chart)，Mockup，Wiki Page形式支持文檔，簡短的討論文案，包括算法和技術要點等等， 都是進一步細化需求的手段。
有人會問，PBI的大小就緒(ready)有什么特征或指導，這里有三個原則供參考：
-
1/2原則：一個PBI或用戶故事(user story)滿足sprinting-able，假如由一個開發人員搞定這個PBI，不應該超過Sprint長度的1/2的時間。???
-
1/4 原則：一個PBI的大小，團隊去實現它，不要超過Sprint長度的1/4時間。?
-
用戶故事點8：大于8個點的用戶故事，給我們一個信號，需要拆分。具體實踐下來，團隊會找到大家認可的基準和公用尺碼，比如2個點的用戶故事意謂著多大的工作量。?
3. 誰來參加PBR（who）？
我們強調全員都參加(inclusive)，即整個Scrum團隊，PBR活動會增加成員的參與感(engagement)。工作坊的形式很重要，用戶故事卡片會自然引發對話。
不像傳統的做法，只有少部分人員或資深的工程師參加。全員參加的好處，保證PO與開發團隊面對面溝通，通過對話的形式理解業務需求，信息對稱。有時候PO會邀請關鍵的干系人(key stakeholders)參加；特別是需求的提出方，或是Feature Owner。Scrum鼓勵開發團隊與用戶的直接溝通，而不是所有的信息都要通過PO，PO不是中間人(middle man)。這種對話SM可充當引導者，保證溝通高效，PO或客戶直接澄清需求給團隊。
這樣做，也許會有人擔心：
（1）業務擔心需求“失控”，開發團隊會對客戶承諾太多。有時候我們擔心研發搞砸(mess-up)，嫌麻煩，所以會找個借口，比如開發人員駕馭客戶的能力不夠，演講(Presentation)能力不“專業”，不邀請他們參加此種會議或對話，圖省事。其實，讓真正“干活”的人第一時間理解為什么要做這件事情比如何做更要緊。把團隊封閉管控起來，不允許與客戶用戶直接溝通，潛在的風險更大。把“正確”的需求做“對”，是我們的共同目標，PO可以在這個“對話”過程中充當引導者的角色，便于管理。???
（2）干系人(包括sponsor和管理者)平時很忙，沒有時間參加此類PBR的活動。每次PBR的活動，PO有責任邀請相關的干系人參加。具體的做法，PBR活動提前在Scrum日歷上固定下來，讓需求相關的干系人可以分時段參加PBR，不需要干系人全程都參加PBR。合理分配好時間，通過面對面的對話，對需求的充分理解，是把事情做對的關鍵一步。
你會發現，Scrum設計的PBR活動，從某種角度解釋，它把敏捷原則的第四條“項目過程日常工作中，業務人員與開發人員必須在一起工作”實實在在的落地了，業務和研發的“協作”變成了具體可操作的“動作”。
4. 什么時候做？(when) 做多長時間？（how long）
PBR是一個持續的活動，一個不好的消息是，Scrum沒有特別“告訴”你什么時候做PBR。推薦的做法：在Scrum的日歷上以工作坊(workshop)的形式把它固定下來，有些團隊叫Backlog Grooming，比如一個Scrum團隊提早約定好在兩周迭代的第二周的周二下午3點到4點半做PBR，屆時大家都會出席, 當然PO要做好充分的準備。Scrum建議開發團隊在每個迭代過程中投資團隊容量(capacity)的5-10%時間協助PO梳理PBL，注意5-10%是一個累加總值，PBR可以在迭代中做多次，有時是估算，有時是拆分，也可能是估算和拆分的混合。? ??
根據我的觀察，PBR的活動分布在Sprint過程中的以下時段:
A. PBR在Sprint 1之前的發布(版本)規劃中或follow-up session，保證第一個Sprint的需求就緒(ready)。
B. 在Sprint過程中安排每周一次或每個迭代一次的梳理活動，時間固定下來，不需要有專人協調時間。
C. 每日站會結束后，安排單獨的小塊時間梳理部分需求，特別是分布式團隊，PO和團隊不在同一地方。考慮到時差和異地的影響因素，不用再單獨協調大家PBR時間。
D. Sprint評審會結束之前，留出一部分時間來一起看看未來的1-3個Sprint要做什么，基于評審會的反饋調整PBL，影響到發布計劃。好處是干系人正好在現場，不需要單獨邀請，節約時間，而且評審會剛剛開完，趁熱打鐵。不好的地方是離下一個Sprint計劃會議太近，有些匆忙，而且評審會已經消耗了能量，需要休整。
最后，期待這篇文章對產品待辦列表梳理PBR的困惑有所解答。如果能參加CSM/CSPO課程，你將體驗到產品待辦列表梳理各項活動：PBI的進一步澄清(業務價值和滿意條件)，估算，拆分，排優先級的技術和實踐。?
Jim Wang王軍
寫于2022年12月5日
參考資料：
（1）?CSPO?教材
（2）?Scrum?指南
（3）《Scrum Essential》 By Ken Rubin?
總結
以上是生活随笔為你收集整理的产品待办列表梳理(PBR)是什么？的全部內容，希望文章能夠幫你解決所遇到的問題。
