#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 MeetingPlanning Meeting
Product Backlog幾乎全部PO從中精選過的Stories
會議目的調整Story、提早曝險解釋與承諾Story、估Point、分配任務
會議長度約30分鐘分兩場(WHAT-Meeting & HOW-Meeting),各約兩小時
範疇整個Scrum當前Sprint
Grooming Meeting vs. Planning Meeting

# 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頁

2 Comments

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。