去年十一月在 Agile Tour Hsinchu 2016 演講〈瓶頸處理九大原則〉時,我曾引用 Essential Scrum 的圖:


後來被老司機提醒:「現在 Scrum 陣營,已經不太用 "grooming" 一詞了,建議改成 "refinement"。」我才第一次發覺,這可能是很重要的活動,才值得 Scrum 陣營特別予以正名。

Refinement?

這是一個在初等 Scrum 書籍中,極少被提及的會議。值得細究。



略做考古,最早的 Scrum Guide 2010 版是用 "grooming" 一詞:

Scrum Teams often spend 10% of each Sprint grooming the product backlog to meet the above definition of the Product Backlog. When groomed to this level of granularity, the Product Backlog items at the top of the Product Backlog (highest priority, greatest value) are decomposed so they fit within one Sprint. They have been analyzed and thought through during the grooming process. When the Sprint Planning meeting occurs, these top priority Product Backlog items are well understood and easily selected.

到了 Scrum Guide 2011 七月版,比較正式給了一個 "product backlog grooming" 稱呼,但還只是視為一個 "part-time" 活動:

Product backlog grooming is the act of adding detail, estimates, and order to items in the Product Backlog. [...] Grooming is a part-time activity during a Sprint between the Product Owner and the Development Team.

到了 Scrum Guide 2013 版,才修正為現在通用的 "product backlog refinement" 一詞,不再視為一個 "part-time" 活動,也更強調 product backlog 的 "ready" 標準:

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. [...] The Scrum Team decides how and when refinement is done. [...] Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above described refining activities.

從這些演進,可看出 Scrum 發明人 Ken Schwaber 及 Jeff Sutherland 在經年累月不斷實踐中,逐步加強對於 product backlog 管理的重視。

從這些演進趨勢,也不難看出後來像 LeSS 這種大型敏捷框架,會正式將 PBR (product backlog refinement) 列為「必要」的 10% 活動:

Ongoing Product Backlog Refinement (PBR) is needed within each Sprint to refine items to be ready for future Sprints. [...] In the spirit of empirical process control, Scrum does not say how to do PBR, though suggests that the Team spend no more than 10% of their Sprint capacity on it. It usually happens “mid-Sprint.”

這代表,不先花 10% 的時間集體進行 PBR,可能會損及未來 Sprint 的效率或效果。

我想分幾個層次來談 PBR 的必要性:

  1. PBR 到底在做些什麼?
  2. PBR 做的那些事,到底有沒有存在的必要?
  3. 如果這些事有必要,那麼,該由誰來做?
  4. 如果這些事有必要,那麼,不在 PBR 做,要在哪裡做?



問題一:PBR 到底在做些什麼?

單從名稱上來看,product backlog refinement,就是在對 product backlog 進行一個所謂的 refinement 的動作。

對象是 product backlog,動作是 refine。

那麼,如何 refine 呢?要 refine 成什麼地步呢?

Scrum Guide 2016 版說:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.

LeSS framework 說:

Key activities of PBR are (1) splitting big items, (2) detailing items until ready, and (3) estimating.

Essential Scrum 有很生動的圖示:

綜合來說,就是對於 product backlog 進行梳理:增刪、拆解、補充細節、估點、排序。



問題二:PBR 做的那些事,到底有沒有存在的必要?

如果先撇開 PRR 這個會議形式不談,純粹只談「對於 product backlog 進行梳理:增刪、拆解、補充細節、估點、排序」這事情。試問:它到底有沒有存在的必要?

我想,答案應該很明顯了。



問題三:這些事,該由誰來做?

如果先撇開 PRR 這個會議形式不談,純粹只談「對於 product backlog 進行梳理:增刪、拆解、補充細節、估點、排序」這事情。試問:這些事,該由誰來做?

這些事,如果可以只由 product owner 一個人做,那就單純多了。可惜,這有違 Scrum 原理。

LeSS framework 說得好:

Refinement of items is not done separately by the Product Owner or a business analysis group—doing that would increase the lean wastes of hand-off and information scatter. Rather, the Team does this work—and not a subset of the Team, but the whole Team, as Scrum rules prohibit sub-groups dedicated to particular domains such as analysis or testing.

看起來,能由整個團隊一起來做,是最好的。



問題四:這些事,不在 PBR 做,要在哪裡做?

現在,我們可以正式來探討 PRR 這個會議形式存在與否的問題了。

既然「對於 product backlog 進行梳理:增刪、拆解、補充細節、估點、排序」這事情,有必要做,也該由整個團隊一起來做,那麼,試問:該在什麼時間做?該在哪裡做?

看起來,最自然的,就是 Sprint Planning 了。但這也意味著:Sprint Planning 要做的事情變多了。

典型的 Sprint Planning 會花多少時間呢?根據《Agile 成功法則》列的時間比例分配表:


以最典型的 2-week sprint 為例,Sprint Planning 最多可能就要花上 4 小時了。4 小時的會議,對許多人來說,很難至始至終維持專注。

想維持專注,除了會議引導技巧之外,更根本的解決之道,就是要讓會議內容聚焦。

該讓 Sprint Planning 會議聚焦在何處?

我在〈以談判角度看 Sprint Planning〉一文曾說過,我心目中高品質的 Sprint Planning 是:

我常引用《執行力的修練》的四大紀律框架來指導敏捷開發活動。其中,紀律一「鎖定極重要目標」也正是 Sprint Planning 的起手式。

只要是我有權主導的 Sprint Planning,都會先花些時間請 PO 重新展開 Impact MappingScaling Lean 的內容,尤其是還沒有穩定扎實 Product Backlog Refinement 的團隊。

我想用結構化的 Sprint Planning 流程,讓錨定效應、以關係為中心、目的型談判自然發生,讓參與其中的人,逐漸在刻意不遮掩的建設性衝突中,潛移默化。

不過,我這種流程設計,對於資淺 PO 來說,應該是備感壓力吧。畢竟,這高度考驗著說故事能力 (story telling) 及參與式決策的開放心態 (participatory decision-making)。可是,少了這些,怎能算是合格的廿一世紀 PO 呢?

經過幾次品質達標與不達標的經驗,我發現,關鍵就在於前置作業確不確實。

如果想在 Sprint Planning 做到以上這些高品質的事情,那麼,像增刪、拆解、補充細節、估點、排序這類的梳理動作,不該佔用寶貴的 Sprint Planning 時段;應該列為 Sprint Planning 召開之前的前置作業,應該抽出到另一個所謂的 Product Backlog Refinement 時段去進行。

Sprint Planning 是一整個 Sprint 士氣的火車頭,不宜消耗在梳理瑣事上。

這也是 TOC 聚焦五步驟的應用:

  1. Identify確認瓶頸:專注的會議時間。
  2. Exploit/決定如何充分利用瓶頸:只進行高品質的 Sprint Planning 活動。
  3. Subordinate/其他一切遷就以上決定:將梳理瑣事移到另一個獨立的 PBR 活動去。
  4. Elevate鬆綁制約因素:提升團隊的 Sprint Planning 效能。
  5. Prevent Inertia避免惰性,回到步驟一。

看起來,我應該更堅持在瓶頸出現時,藉由 Retrospective 的機會,闡述 Product Backlog Refinement 活動的必要性。


▷ 後續文章:〈從 Ready 角度看 Product Backlog Refinement〉及〈Product backlog refinement 文章小蒐集