產品代辦清單梳理會議 (Product Backlog Refinement Meeting) 這是一個很饒舌的名稱, 用來釐清團隊處理的事項內容. 最近社群中不少人提到這個東西, 因此也湊熱鬧來整理一下.
什麼是 Product Backlog Refinement Meeting
讓我們看看這些解釋:
(1) Scrum Guide
英文
|
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
|
中文
|
產品待辦細部化是一種將產品待辦增加細節，更詳細的預估，和項目的重要排列的動作。
細部化是一個持續的流程，在這流程中產品負責人和開發團隊協同工作在產品待辦項目的細節上。
在產品待辦細部化過程中，項目們被重新檢討和修訂。Scrum 團隊決定如何來完成細部化以及何時來完成。細部化通常以不超過開發團隊百分之十的產能為上限。
然而，產品負責人或者其它人在產品負責人的斟酌下，產品待辦項目可以在任何時間來更新。
|
(2) Scrum Inc
Product Backlog Refinement
Scrum Inc 是發明人Jeff Sutherland 所開的公司, 他們認為 Product Backlog Refinement 需要處理這些事情:
細部需求的分析
把大的待辦事項切割成小的
評估新的待辦事項
對現存項目重新評估
(3) PSM™ Scrum Master Training Dublin & Cork
這一系列的 video 很適合初學者. 如果你對 Scrum 不熟, 可以透過它有個基礎的暸解.
What is the Backlog Refinement Meeting?
歷史
當年, 印象中 Scrum 一開始是沒有這個會議的. 早期 2009 年我們在實施 Scrum 時, 在 sprint planning meeting 花了很多時間, 因為那時候要決定要拿多少 product backlog item 進來, 是一件不容易的事. 我們對那些 product backlog item 是什麼並不清楚. 所以把會議時間拖了很長.
之後, 我們就想說山不轉路轉, 我們那時候是個 2 週的 sprint, 我們就在第 2 週的星期三或星期四, 每次會找相關的工程師, 一起討論下個 sprint 要做的一些功能. 好讓我們下次 sprint planning 時, 可以進行得比較快.
沒想到之後 Scrum 就加入這個 practice. 那時候心裡覺得還滿爽的, 團隊自己的改進方向, 和世界潮流還是一致的.
別名
早期有些人把 Product Backlog Refinement Meeting 叫成 Product Backlog Grooming Meeting. 但是後來就都叫 Product Backlog Refinement Meeting. 在網路上有此一說, 是因為 Grooming 這個字有不好的意思(見下面), 所以就改成 refinement.
常見狀況劇
(1) 同時談太多東西
有些 PO 很貪心, 想要一次把很多 product backlog item 談完. 這不是大胃王比賽, 沒有多少團隊可以一次吃這麼多, 通常下場都是吐出來, 大家接收不進去, 所以有開跟沒開一樣.
(2) 是否全員參加
Scrum Guide 中沒特別說, 是否所有的人都要參加. 但是若有很多東西要討論, 所有的人都來, 那個代價是不小. 建議不同 product backlog item 分開不同會議, 每次談一個功能, 只找相關的工程師, 他們是一定要參加, 但是其他人是可自行決定. 我目前遇到的團隊, 大約八成左右會參加, 所以看起來效果還可以.
(3) 想一次搞定
有些需求很複雜, PO 又很貪心, 因為怕人不好找齊, 所以想一次就把他談完, 導致最後大家精神不濟, 虎頭蛇尾. 我們會覺得應該是要定期定量召開. 例如, 每次一小時, 每天一次.
(4) 忘記找關鍵人
有時候團隊為了趕快談需求, 就先召開會議下去聊了. 可是能解釋需求的 PO 或是用戶沒來, 或者是懂關鍵技術的人不在, 這樣開會的結果通常也會白搭, 往往還會需要再講一次.
(5) 沒有需求準備好的定義
有時候 PO 太不盡責, 寫出來的 story 太”精簡”, 這時候適當的 Definition of Ready 是需要的. 提醒 PO 的 story 至少要有適當的資訊. 不是要用這個來擋 PO, 而是希望所提出來的 story 是可以讓大家進一步討論和評估的.
(6) 忘記更新產品待辦清單
在大家討論需求很熱烈的狀況下, 太專注要做的故事上面, 可是忘記回去更新 product backlog 的內容或順序. 所以造成 product backlog 容易有遺漏, 不是最正確的內容.
(7) 沒有安排 refinement meeting 的時間
很多團隊在 sprint planning meeting 時, 大家就認領了滿滿的工作, 根本就沒有留時間去做其他事情. 這時候你要塞很多場 Product Backlog Grooming Meeting, 這對大家來說會很崩潰.
(8) 不用想看太遠
PO 或團隊有時候想太多, 想要看 4 或 5 個 sprint 後的 story. 基本上, 不用這麼早開始想這麼久遠, 那麼後面做的東西, 需求都有可能會變動, 就算要看的話, 應該只是 PO 和用戶談天, 不該讓團隊下去一起談, 這樣的投資可能都回收不回來.
ok, 打完收工
全站熱搜
留言列表
