- PBL: Product Backlog，產品的工作項目清單
- PBI: Product Backlog Item，產品的工作項目
身為 Scrum 團隊的一員，每個 Sprint 的重要任務之一，就是搞懂 PBL (Product Backlog) 上的項目，想辦法實現它。
Scrum 跑了一陣子，PBI 也出現過好幾種的寫法。三不五時都會討論一下哪一種表達更清楚好懂。這次就針對兩種寫法來做一點比較。
寫法一
- 異動記錄：匯出記錄功能
- 監控系統：發送通知
寫法二
- 異動記錄：使用者想要匯出記錄，以便做進一步分析
- 監控系統：為了確實掌握系統即時狀況，在XX事件觸發時通知到通訊軟體
寫法一：直接寫出施工項目
PO 把希望工程師做什麼寫成 PBI，範例如下：
- 異動記錄：匯出記錄功能
- 監控系統：發送通知
當然只寫這樣的 PO 一定會被工程師問說：這樣寫太簡單，不知道要做什麼，需要更完整的資訊
這時會產生更多資訊的寫法：
- 異動記錄：增加匯出按鈕，匯出最近 30 天的記錄
- 監控系統：發送事件通知到 Line 群組中
這樣的 PBI 在 Planning Meeting 時，大概會有幾個討論走向：
討論細節
- 這是我認為是最不好的走向。
- 工程師開始討論畫面要怎麼設計，資料庫的欄位跟型態有哪些。
- 過早的討論細節是在浪費時間，細節講越多越會分散大家的注意力，減少對目標的討論。
詢問 PO 為什麼要提供這樣的功能
- 工程師想要尋找 PBI 背後的用途，避免做白工。如果發現有更簡單的方法，會更改 PBI 的內容。如果發現對使用者沒有幫助，就直接刪掉 PBI。
- 討論的時間會花比較多在探索使用者可能遇到的狀況。
寫法二：描述使用情境
PO 把把使用者遇到的狀況寫成 PBI，範例如下：
- 異動記錄：使用者想要匯出記錄，以便做進一步分析
- 監控系統：為了確實掌握系統即時狀況，在XX事件觸發時通知到通訊軟體
這樣的 PBI 在 Planning Meeting 時，大概會有幾個討論走向：
了解情境，提供施工方案
- 工程師會深入的了解使用者遇到的情境。
- 試著提供一些施工方案，評估方案對使用者的價值。
討論 PBI 可以整合或是拆開
- 有時候 PBI 過大，可能需要被拆開來分別去完成。
- 當然也會有 PBI 比較小，工程師直接給出一個方案一次解決多個 PBI。
- 討論的時間會花比較多在如何交付更有價值的產出。
如果寫成使用者故事(User Story)
User Story 的造句形式：
- As a ___, I want ___, so that ___.
- 身為 ___，我想要 ___，以便 ___。
如果依使用者故事的形式寫：
- 異動記錄：身為OO使用者，我想要匯出一個月的記錄，以便提供給XX部門做分析
- 監控系統：身為值班人員，我想要在通訊軟體收到XX事件觸發通知，確實掌握系統即時狀況
有些人會覺得依照使用者故事的形式寫，標題會太長。
那麼就保持使用者故事的元素都在裡面的句子，效果也是相當的。
使用者故事的元素 (也就是造句形式的空格)，分別是：誰(who)、做什麼事(what)、為什麼(why)
範例如下：
- 異動記錄：為了提供記錄給XX部門做分析
(why)，使用者(who)想要匯出記錄(what) - 監控系統：值班人員
(who)為了掌握系統即時狀況(why)，想要在通訊軟體收到XX事件觸發通知(what)
寫法比較
以下是我個人工作上的經驗跟觀察
- 以故事/情境的方式來說明 PBI，比較容易讓人感受到它的目的。
- 描述方式的差別會引導大家往不同的方向思考跟討論，透過了解使用情境產生的討論，通常比較容易從各種角度聚焦回使用情境上。
- 不會是為了做而做，有價值的項目才有做有意義。單純的功能無法產生價值，有使用者才會產生價值。
回頭以 PO 的角度看看
- 身為 PO，我想要 PBI 描述的施工項目被完成，以便交付項目給使用者
- 身為 PO，我想要 PBI 描述的情境被滿足，以便增加系統對使用者的價值
哪個選項比較好呢？