產品的需求很難一下就梳理完畢, 如果一開始要把所有東西都釐清, 開發團隊將會花很多時間在等待, 產品負責人將會變成瓶頸. 因此, Product Backlog Refinement 會議的作法便是一個很好的折衷方式. 先將下一個或是兩三個迭代要做的需求給釐清, 讓團隊可以早點開始. 並且也避免萬一需求變動, 導致之前所花的努力變成白費.

所以, Product Backlog Refinement 在 LeSS 很重要, 它是一個正式的事件 (Event), 而非只是一個活動 (activity) 而已. 之前在 Scrum Guide 中, 被視為事件 (Event)的, 只有 Sprint, Sprint Planning, Daily Scrum, Sprint Review 和 Sprint Retrospective. 而 Product Backlog Refinement 則被視為以下活動

Product Backlog 的精煉是將 Product Backlog items 拆解並進一步定義，使其變得更小、更精確的活動。這是一項持續進行的活動，加入更多描述、順序與大小之類的細節。這些屬性通常隨工作領域而不同。

在 LeSS 中進行 Product Backlog Refinement, 建議不事先指定給特定團隊去梳理某個需求. 如果先指定誰梳理什麼, 會導致失去敏捷度, 因為都事先規劃好, 沒有彈性可言. 另外, 也失去了學習機會, 沒有先指定好, 才會有豔遇發生, 才會學到想不到的東西.

如果讓所有成員都參與某個需求的梳理, 這時候討論可能會花很多時間, 導致需求討論不完. 另外, 也不見得每個人都能很專心, 或是對這個需求有興趣. 因此, 需要有適當的分組, 一方面讓討論有效率. 另一方面, 也讓有興趣和願意貢獻的人參與. 所以, 我們在設計 Product Backlog Refinement 要考慮這些事情, 讓整個活動可以平衡這些優缺點.

在 LeSS 中, Product Backlog Refinement 的進行, 如下圖所示, 分成兩個部分

第一部分: 利用 總體 PBR, 進行快速和總體的需求介紹和了解.
第二部分: 利用 單團隊 PBR 和 多團隊 PBR 進行詳細的需求釐清.

圖片來源: https://less.works/less/framework/product-backlog-refinement

上面提到的總體 PBR, 單團隊 PBR, 多團隊 PBR, 以及之前提到的初始 PBR, 都是要進行需求的釐清, 只是因為時機對象不同, 所以會有不同實施重點. 以下是這四個 PBR 變形的概略比較. 如果要進一步知道其細節, 可以看各自的介紹.

參考資料: Large Scale Scrum – More with LeSS

總體 PBR (Overall Product Backlog Refinement) 會快速進行介紹需求, 以及決定接下來要以怎樣的方式進行需求的討論. 所以整個會議的時間不會太長, 對於一個 2 週的迭代, 大約至多花一個小時的時間. 參加的人包含產品負責人, 所有團隊成員或是團隊派出一些代表來參加.

(1) 討論方向和願景

產品負責人會大家說明這些功能背後的願景, 為什麼我們需要做這些功能, 客戶遇到了什麼問題. 也就是會交代這些功能的相關背景資訊.

(2) 簡介要梳理的需求

產品負責人簡單介紹一下這次要討論的功能是什麼, 並不需要很深入的釐清. 這裡
有個小技巧可以使用, 每個需求限制討論的時間, 例如至多 8 分鐘, 讓討論集中在重要的事情上面, 不會因為細節而無限拉長.

(3) 分配要釐清的故事

團隊接著會需要對這些故事進行進一步的討論和發想. 為了可以有效率地進行, 會需要分成幾個小組來討論. 這些小組可能是原來的團隊, 或者是混合編組, 或者是有興趣的人就去參與, 這邊可以有很多嘗試.

另外也可能這個需求比較複雜, 關係到原先多個團隊, 例如之前某個團隊做過, 或者是某個團隊有這方面的專家, 因此需要這些團隊各派一些代表來討論.

所以這個過程中, 會一邊詢問這個需求那個小組要釐清, 或者確認是否要形成新的討論小組來處理. 但是不建議是否個團隊最擅長哪個功能, 就都是交給他處理. 當然啦, 有些組織怕這樣做會大大影響交付時程, 或者是本身都不會時去討論可能也無法貢獻, 這時候可以分配個比例, 例如 80% 都是拿自己熟悉或之前做過, 20% 可是嘗試自己不熟的. 讓團隊有學習的機會, 但有能適當地兼顧計畫的時程.

建議是由團隊來決定由哪個團隊釐清哪個需求, 或是由哪幾個團隊一起討論. 這件事情最好不要讓產品負責人來決定. 一方面, 讓團隊養成自組織的習慣. 另一方面, 也減少產品負責人的負擔.