#Scrum 那些會遇到的大小事【一】– Sprint Grooming Meeting

現實狀況，可能更為複雜且彼此環環相扣，本系列僅提供參考

簡介

Sprint Grooming Meeting_[1]，亦稱Sprint Backlog Refinement Meeting。

• 參與人員：Scrum Team Members, Product Owner & Scrum Master
• 會議時間：按需或預定每個Sprint兩次，每次30分鐘
• 會議主要目的：PO與團隊同步Product Backlog，進行新增、修改、刪除與重新排序User Story

在Grooming之前，PO會有依照實際需求而制定好的一份Product Backlog，在Grooming會議中，PO可以適當的讓團隊了解這份Backlog的大致方向。例如，今天要開發一個遊戲數據報表App，客戶提到幾項主要需求：

• 觀看整體營運數據
• 觀看各遊戲相關資訊（營運、流量、伺服器狀態、問題回報等等）
• 部分資訊需以圖表或表格呈現

PO根據這幾個需求，先初步轉化為User Story，而團隊成員在會議中提出想法，例如某一個Story可能過於龐大，建議可以拆分（Size User Stories Correctly）；哪一個技術是團隊不足或缺少什麼權限與資源（Uncover Risks, Identify Dependencies）；再PO適當評估後，針對Story進行優先順序調整（Prioritize User Stories）

---

# Grooming Meeting與Planning Meeting有什麼不同？

Grooming Meeting是針對整份Product Backlog去研討，而Planning Meeting是Product Backlog精選後的部分Stories。

比較	Grooming Meeting	Planning Meeting
Product Backlog	幾乎全部	PO從中精選過的Stories
會議目的	調整Story、提早曝險	解釋與承諾Story、估Point、分配任務
會議長度	約30分鐘	分兩場（WHAT-Meeting & HOW-Meeting），各約兩小時
範疇	整個Scrum	當前Sprint

# Grooming Meeting時該定義好DoD嗎？

Grooming主要是針對需求面，因此可以先釐清的是Acceptance Criteria（以下簡稱AC），而非DoD_[2]。在規範中，沒有明確定義Grooming是否該定義AC，但適度的讓Story趨向精準，多少能避免開發中遇到突如其來的狀況。過去參與的Grooming，團隊通常會七嘴八舌，會問很多技術面或更Detail的問題，此時PO肯定很無奈（心想都花那麼多時間整理了，怎麼還有那麼多問題…）

# Acceptance Criteria一直改、一直加怎麼辦？

Scrum本身就是不停地迭代、修正與執行，及早發現問題、需求，儘早排除困難。不管Sprint是否在進行，AC發生變動時應該被重新評估、建立新的User Story，並放到Product Backlog中。

這時候可能會有疑問，如果AC改動很小，不能請開發團隊直接改嗎？這樣也太沒效率了吧。

過去很常遇到這樣的狀況，但有時開發端與需求端對改動的成本認知會有落差，比如曾經遇過的是：

• 上次有改過「類似」的，但這次怎麼改比較久
• 只是加個按鈕，怎麼會壞掉其他地方

發生這種狀況，最有可能的原因是，程式碼牽扯到模組與測試。在這種成本認知不對稱的情況下，可能會造成誤會，同時影響Sprint的進行（Velocity）。

因此遇到這樣的狀況，我曾經做過一個小實驗：當需求端提出想要改動AC時，我堅決地提議，是否可以建立新的故事，並在下一個Sprint進行。後來團隊產生了幾個變化：

1. Scrum Team Member更能專注在Sprint上
2. 團隊成員彼此間取得更多的信任
3. 團隊建立了明確的原則，再往後的Planning Meeting，PO會更充分的提出與描述Story與需求

此時可能會有些質疑，這樣團隊會不會逐漸消極，因為貌似沒有「插件」了。這個部分將在之後有關「Velocity」的章節分享～

# Grooming沒開會怎麼樣？

Grooming的目的，說白的就是為Product Backlog作「健檢」。團隊適時維護Product Backlog，可以讓Story的Priority與Point是合理且被關注的。除了可以確保Planning Meeting的順利，也可以讓Velocity是合理的。

過去由於PO沒有時間開Grooming，因此都是在Planning Meeting上半場才估Point。除了會延長Planning的會議時間，估Point也可能會失準。Velocity因此變得沒有參考價值。

參考資料

[1] THE SCRUM FRAMEWORK TRAINING BOOK BY INTERNATIONAL SCRUM INSTITUTE™，第84頁
[2] Definition of Done vs Acceptance Criteria
[3] THE SCRUM FRAMEWORK TRAINING BOOK BY INTERNATIONAL SCRUM INSTITUTE™，第20頁