[Agile] 估算團隊在Sprint的Speed & Scope

 #Agile    #Scrum 

▌背景

---

此篇文章是在Agile Tour 2015， 參加 91大 的「Scrum Estimation Model」課程後， 所做的練習。

在實務及觀念上，我需要加強的地方很多! 因此文章中如果有不正確的地方，也請各位提點! 感謝!!

▌流程

---

▋定義簡單的Story Point表示方式

為了讓PO更簡單的判別工作項目的大小， 我們以L, M, S定義三種不同的工作項目Size， S的Store Point先隨便給個10；  M相對於S，可能需要三倍的時間， L相對於S，需要五倍的時間； 所以定義Story Points如下：

Size	Story Point
L	50
M	30
S	10

▋Sprint 0

假設我們團隊除了既有的Web Form系統維護，老闆要求要開始一個建立新的.NET開發架構 (MVC + Restful + DDD)專案；  於是Team討論出來的Product backlog如下圖； 我們以兩周(十天)為一個Sprint， 在尚未得知目前此專案的Speed下， 我們先選擇兩項工作為Sprint 0 的Scope； 在Daily Meeting持續做追蹤或是Refinement。

▋Sprint 0 Retrospective Meeting

在Sprint 0 Retrospective meeting， 發現其實我們已經在一個Sprint完成了三個工作項目（如下圖）， 完成的Story Point = S*1 + M*2 = 70 ， 

所以以Sprint 0的經驗告訴我們，可以在兩周一個Sprint完成共 70 Story Points的工作。這個就是Team的Speed。  但是Speed在每個Sprint結束後，便會和上一個Sprint的速度開始有差異 (例如：成員臨時請長假或是離職)， 因此需要樣本數夠多來做平均，才會越來越精準。 如果需要更精準的數字，可以採用例如 蒙特卡羅方法（Monte Carlo method）。

PS. Y 軸： Story Points,  X軸：The week of the sprint

▋Now we have a deadline !

接下來，PO說老闆期望可以在接下來的兩個月 = 4 Sprints完成所有事情。

以我們的速率 70 Store Points/1 Sprint  * 4  =  280

也就是說，我們估計這兩個月只能完成 280 Store Points的事情；

撇開Sprint 0已完成的項目，其他的工作項目總SP = S*2 + M*5 + L*3 = 320

也就是有 320 – 280 = 40 的工作，是無法如老闆期望內的日期完成的。

這時候，我們有幾個選擇：

1.  延長時程

多餘的40 SP的工作，需要額外的一周(備註)才可以完成；  請PO再溝通。

PS. 因速率為 70 Store Points/1 Sprint， 所以40 SP的工作約需1/2 Sprint=1 Week。

2.  調整Priority 或縮小Scope

隨著專案的進行，其實有一些工作項目是不需要、或是很不重要。 這時候，我們可以和PO確認，將這些工作移除或是優先權放到最後面，將Scope減少。

3.  技術上的調整

例如某個工作項目原本要求是自行開發， 因此Size是L， 這時候可以討論是否買現成的模組來套用？ 或是減少一些測試和文件的流程？ 將其Size (Story Point) 降低。 

4.  加班

加班就是強硬的增快Team的Speed， 讓原本的 70 Store Points/1 Sprint  

可能因此暴增為 100 Store Points/1 Sprint； 來解決時程的問題。

但是91 大也強調：  加班是會產生技術債的!!  總有一天要還的!!

▋Refine and Retrospect

前面有提到，團隊的速率是時時刻刻在改變的， 所以每次回顧的時候， 必須再次校正一下。 另外一開始訂出來的工作項目Size， 隨著每次Sprint的開始和結束， 可以依據團隊的討論去調整SP或增加、減少Size定義。

當然Size一多，就失去了它的意義； 有的時候，可能將工作項目再Break down， 會更加有效率~!

▌Reference

---

估算需求複雜度（3）如何評估專案時程