Sprint planning meeting的四種方式

Dec. 06 10:38~11:46

 

今天談一個基本的問題：Sprint planning meeting（衝刺計畫會議）進行的方式。

區分Part 1、Part 2

Sprint planning meeting可以區分為part 1（上半場）、part 2（下半場），前者討論需求內容（what to do），後者討論實作方法（how to do）。常見的進行方式為：

1. 在part 1由Product Owner解釋這個sprint所預計要完成的story內容，團隊成員可以透過planning poker對story進行估算（估算相對大小或是T-Shirt size）。在此估算的主要目的是溝通團隊成員對於需求的理解，拉近彼此對於需求範圍的共識。
2. 在part 2由團隊成員將每一個story切割成若干個task，例如設計UI、設計資料庫表格、撰寫stored procedure、撰寫若干個classes等。接著團隊成員利用planning poker來估算完成每一個task所需的工時。與估算story類似，這裡的估算其主要目的也是溝通團隊成員對於task的理解，拉近彼此對於task範圍的共識，而不是要獲得一個精準不可動搖的「工時估計」。

Sprint planning meeting進行方式在概念上就是如此。看到這裡鄉民們可能會有一個問題：「怎麼知道這個sprint可以做多少story？」有兩種常用的方式：

• Velocity based：依據之前每個sprint所完成的story point為參考基準來決定這個sprint可以做多少事情。
• Commitment based：一次挑一個story，直到團隊認為無法完成更多的story為止 。

***

Part 1、Part 2交錯進行

概念上sprint planning meeting可以區分為part 1、part2，但實際進行方式並不一定要part 1執行完畢才進行part 2，也可能估算完一個story之後，馬上就對這個story進行切割task，也就是part1、part 2交錯進行。

有些團隊會使用團隊成員這個sprint可以投入到專案的工作時數來作為挑選story數量的依據，將part 1、part 2交錯進行，可以避免part 1 討論太多story而在part 2估算工時之後才發現根本做不了那麼多功能。

***

Part 2採用Just In Time方式進行

還有一種方式是團隊在part 1決定這個sprint可以做多少story之後sprint planning meeting會議就結束了，等到每一個story要被施工的時候才即時切割task。這麼做的好處是，可以讓團隊聚焦在同一個高優先權的story一起完成（因為優先權比較低的story還沒被切割成task），也可以減少事先切割所有story的task但最後有些story沒做完所造成的切割task時間浪費。

這種方式的缺點，因為每次只看一個story，如果story之間有比較緊密的關係或相依性，可能造成見樹不見林的現象，在實作後面的story的時候才發現需要回頭修改原本已經完成的story。

***

根本沒有Part 2

有些團隊把story直接綁定在團隊成員身上，由一個或是一對成員完成一個story。只管團隊成員是否了解story要做什麼（what to do），而不管怎麼做（how to do），因此也就不需要part 2來切割task的團體活動。認領每一個story的團隊成員自己決定要如何完成這個story，要切不切task都可以（就算切了task也沒人會來幫你做，因為別人都在忙自己手上的story）。

***

依據專案與團隊成員的特性，以上四種方式都有人使用。什麼，你問除了以上四種還有沒有其他方式？等鄉民們跟Teddy分享。

***

友藏內心獨白：可以沒有part 1嗎？