當進行完 Product Backlog Refinement 第一部分後, 接下來要對需求進行詳細的梳理, 好讓之後開發時可以很明確知道要做什麼, 以減低產品負責人, 客戶, 和團隊之間的誤解.

在這階段時我們有兩種進行方式： (1) 單團隊的 PBR, 和 (2) 多團隊的 PBR. 顧名思義, 就是在進行需求釐清的時間, 是由多少團隊一起來做的. 一個是一個團隊, 另一個是 2 個以上的團隊. 那為什麼我們需要多團隊 PBR 呢? 主要是以下原因:

(1) 增進協作與學習

如果你希望養成習慣, 最好的方式就是刻意練習. 因此為了讓團隊能增加協作能力, 並且保持對系統整體不斷學習, 利用多個團隊一起釐清, 便是一個不錯的練習. 一方面是做工作上的事情, 另一方面, 這個活動所花費的代價不會太大. 不見得每次迭代都要做, 或者是所有團隊都要做.

(2) 同儕壓力

當人們在自己團隊工作, 挑選自己熟悉的需求去梳理, 容易造成誤以為自己很了解一切的誤解. 為了讓你離開這樣的舒適圈, 我們會安排多團隊 PBR, 讓你接觸不同的客戶, 以及不同的團隊成員. 你可以看到別人懂的東西和你不同, 以及別人可能問出不一樣的問題. 在這樣的刺激之下, 會讓你有些壓力, 知道自己有哪些地方不足或是不懂, 讓你有動力學習.

(3) 彈性的調度

因為有多組團隊一起梳理這個需求, 因此日後將會有多個團隊可以實作這個需求, 當有外界變化緊急進來時, 團隊將會有彈性去調度, 不會老是只能誰去做某一個需求.

在進行PBR 第二部分時, 有幾件事情要記得進行

(1) 對需求進行估算

這裡是進行初步的估算. 敏捷的估算重點不在於要一個準確的答案, 而是希望藉由這個過程中, 確認大家是否還有疑問, 並且交換對方可能不知道的資訊, 讓大家對於需求的內容可以有共識.

(2) 對需求撰寫驗收條件

確認需求是否真的有共識, 是否大家都了解, 最好的方式便是利用驗收條件來描述需求, 透過範例讓大家對需求沒有太多想像. 這些範例也可以刺激大家想出更多可能的場景. 另外, 有了這些驗收條件, 可以幫助估算, 因為這些範例可以匡出範圍, 有範圍就可以讓估算準確度提高.

(3) 確認需求是否需要再拆解

有時候需求太複雜, 從梳理完後的範例數量可以得知, 這時候需要考量將他做適當的拆解. 通常我們對於大的東西, 估出來的數字數差比例會比較大, 但是對於小的東西, 誤差的比例就還可以. 這時侯的拆解, 對日後工作時程的準確性, 以及團隊成員的士氣有幫助.

(4) 確認需求是否清楚完整

有些時候需求可能沒有想清楚, 或者是某個關鍵部分資料不足, 或者不知道要怎麼做, 這些狀況沒有在 PBR 階段找出來, 而是到 Sprint planning 才發現, 這樣會浪費更多.

單團隊 PBR (Single-team PBR)

基本上單團隊 PBR 的作法, 和傳統 Scrum 中進行的方式一樣. 有以下事情需要注意：

• 通過範例來釐清細節, 讓大家達成共識. 大多以實例化需求流程來進行
• 試圖將大的需求拆解成小的需求
• 當需求有修改或是拆解, 記得持續更新故事地圖
• 確認拆解後項目的優先順序
• 識別出可能的風險或障礙
• 記得要粗略估算一下需求的大小

至於這個要花多少時間. 這個問題很難回答. 以往 Scrum Guide 提到最多大約佔整體時間 10%, PBR 就如開車時的遠光燈, 何時要開遠光燈? 只要路況不明, 就可以考慮要開遠光燈. 同理, 把遠光燈換成 PBR, 其他部分也同樣成立. 只要接下來要做的需求不明確, 便需要召開.

多團隊 PBR (Multi-team PBR)

在 PBR 第一部分時, 就會簡單地帶到, 這些 PBI (Product Backlog Item) 等下要誰來釐清, 是某個團隊, 還是多個團隊. 這些會被分配好. 如果是交由多個團隊來釐清, 接下來就會進行多團隊的 PBR.

一般來說, 是這些團隊的成員都要參加, 以及任何有這個 PBI 相關知識的人也要出席, 像是領域專家, 架構師, 和客戶等等. 以確保在討論時, 所有觀點有被考慮進去. 因為人數比較多, 進行的時間可能會需要到2 個小時.

會議一開始時, 產品負責人會先簡單介紹一下各個 PBI, 以及相關的目標為何. 通常這些 PBI 是貼在牆上, 大家都可以看得到. 並且可能會依優先順序排好. 接下來就要讓這幾個團隊去釐清, 進行的方式可以有以下幾種:

(1) 部分轉隊

假設有三個團隊, 在一開始的 session 分成 3 個討論區, 每個討論各負責一個 PBI, 每個討論區會有一個團隊在討論. 等到這個 session 結束, 這個團隊只會保留一個人, 其他的人便一起往下個討論區去討論下一個 PBI. 等到一個 session 結束後, 又再往下一個討論區前進.

(2) 全部轉隊

和各一個方法不同之處, 這個方式是團進團出, 整個團隊一起一到下一個討論區, 去討論另一個 PBI.

(3) 發散和合併

在第一個 session, 每個團隊待在某一個討論區討論, 等到 session 完後, 這個團隊會分散他的成員去不同的討論區. 所以在第二個 session 中, 每個討論區會有不同團隊成員具在一起討論. 等到第三個 session, 所有人會回到原先團隊的討論區, 繼續討論原先的 PBI.

所以結合上面這些 PBR的作法, 有可能的 PBR會議時程如下

時段 會議主題
09:00-09:50 總體 PBR
介紹 10 分鐘
梳理 25 分鐘
結論 15 分鐘
10:00-10:10 多團隊 PBR 分工介紹
10:10-11:00 多團隊 PBR 第一回合
11:10-12:00 多團隊 PBR 第二回合
13:00-13:50 多團隊 PBR 第三回合
14:00-15:00 分享 PBR 結果

這裡可以看出總體 PBR 和 多團隊 PBR 一起進行, 總體 PBR 不會花太多時間, 只是高層次的介紹, 重頭戲是多團隊 PBR.

下面是另一種進行的議程, 這是將總體 PBR 和 多團隊 PBR 分開舉行. 讓大家可以有消耗的時間. 此外也不會弄一個很長的會議, 搞得大家精疲力倦的.

Day A: 總體 PBR (1 小時)
Day B: 多團隊 PBR ( 4 小時)

另外, 當你分成多次來進行 PBR 時, 萬一這個過程時有需求進來, 或是需要優先順序調整, 或者需求有變, 這時候因為 PBR分成多次進行, 讓團隊有機會可以立即反應需求的變化. 早點知道, 早點反應和調整.