首頁 專案管理
為什麼敏捷團隊應該做兩級估算 產品待辦列表及Sprint待辦列表
2020/10/1 作家:UPerform優普豐敏捷學院
697
作者/UPerform優普豐敏捷學院

對於敏捷團隊,尤其是Scrum團隊來說,對產品待辦列表和Sprint待辦列表進行估算是件很常見的事情。同時估算非常有用,因為估算它們的目的是不一樣的。


估算產品待辦列表的目的
需要去估算產品待辦列表的主要原因有三個。

首先,團隊和產品負責人需要對到某個時間點可以交付什麼樣的價值,做出一個長期一點的預測。這使得團隊可以應對下面的問題:

1.在三個月內可以交付出多少東西?
2.這一系列功能什麼時候能交付?

其次,它可以幫助產品負責人進行優先級決策。工作項的優先級應該基於它的預期收益和實現成本。當一個工作項的估算是3個故事點,或者3天又或你想使用的任何單位,通常優先級都要比它的估算值是100時要高。

我們大多數人,包括敏捷專案的產品負責人,都無法用不考慮成本的方式做出決策。所以在確定工作的優先級時,我們需要考慮開發它的成本。對於大部分的工作項,所涉及工作量的估算是其成本的最大組成部分。

對產品待辦列表中的工作項進行估算的第三個目的是,團隊成員通過充分的考慮和估算,可以對產品相關工作項有更多的了解。這就意味著將來在開發該功能時不會有太多「驚喜」。


估算Sprint待辦列表的目的
現在,我們再來看看為什麼團隊還應該對Sprint待辦列表進行估算,其中有兩個目的。首先,它可以幫助團隊確定有多少工作需要放到當前Sprint去完成。

通過將工作項分解為獨立的小任務,然後在Sprint計劃會上粗略地對它們做出估算,團隊可以更好地評估工作負載。這增加了團隊完成他們所承諾工作的可能性。

其次,在Sprint計劃會上確定並估算任務可以幫助團隊成員更好地協調工作。例如:如果沒有對Sprint待辦列表做過估算,則團隊可能不會注意到完成迭代工作的關鍵路徑,或者在這個迭代中某個角色,比如:設計師將會比其他人更加繁忙。


為什麼要以不同的單位進行估算?
由於對Scrum團隊的兩個不同待辦列表進行估算的用途是不一樣的,因此估算所使用的單位也應該不一樣。特別是對於產品待辦列表項,估算的效率至關重要。

我們來看看原因,假設老闆要求團隊估算什麼時候可以交付40個用戶故事形式的產品待辦列表項。

這完全可能是個合理的請求。如果專案花費的時間太長,老闆可能想知道是否需要再多加幾個人到團隊裡。又或者,老闆只是希望在某個合理的日期來啟動專案。如果團隊要通過將每個用戶故事分解成任務然後去估算每個任務來回答老闆的問題(如在Sprint計劃會中通常所做的那樣)那麼估算所花費的時間將是巨大的。假設我們要平均進行15分鐘的討論並估計每個用戶故事(這是Sprint計劃會中通常需要的),那麼把40個用戶故事估算完將需要整個團隊600分鐘(10個小時)的時間。

如果團隊可以對產品待辦列表項使用更高層次,但同樣差不多準確的估算,則通常可以更快一些。我建議團隊能平均在三到四分鐘內估算一個產品待辦列表項。這樣的話,估算40個用戶故事將花費不超過160分鐘。所以最好的方法是讓團隊按故事點估算其產品待辦列表項,並按小時來估算其Sprint待辦任務。

這種方式之所以能很好地起到效果,是因為故事點是一種具有不同優勢的團隊成員可以達成共識的更抽象的衡量標準。正如你和我可以就「一隻腳」的長度達成共識一樣,即使我們的腳極有可能長度不一樣也沒關係。這樣具有不同技能的敏捷團隊成員,也可以就某個用戶故事所需完成的工作是前一個的兩倍達成共識。

但是,故事點在Sprint這個級別不會起作用。在進行Sprint計劃時,請記住目標是確定團隊這個Sprint要進行的工作量。對於諸如故事點之類的抽象單位而言,這很難。用小時數就要簡單很多。

在Sprint待辦列表中用小時數進行估算是可行的,因為Sprint所包含的項目通常少於整個產品待辦列表項列表,這意味著它不會花很長時間。另外,通常Sprint內一個任務只會由一個人來執行。而且在很多情況下,一個任務產生後就能夠很清楚誰會去做它。這些因素使得以小時為單位來估算SprintBacklog成為可能。


什麼時候進行產品待辦列表的估算?
眾所周知,在創建Sprint待辦列表時,Sprint待辦列表項估算是Sprint計劃會的一部分。但是,團隊應該在什麼時候進行產品待辦列表項的估算?
我建議在兩個不同的時間點去估算產品待辦列表項。第1個估算的時機,是在故事寫作研討會之後的一到兩天。

我建議這是一個產品負責人應該大概每個季度都要組織團隊進行的會議。會議目的是識別出所必需的用戶故事,用於實現若干個版本計劃(每個計劃通常大於1個Sprint)。我們可能會花2-4個小時(每季度)去識別這些產品代表列表項,然後再花1-2個小時再對它們做出估算。

以Sprint為周期,如果自上個Sprint以來,產品待辦列表中的事項有更新,則這是團隊第二個對產品待辦列表項做估算的時機。這個可以隨時去做,但最好是在一個Sprint相對靠後的階段,以最大程度地避免在下個Sprint開始前又出現新的用戶故事。通常,這可以在團隊的產品待辦列表項梳理活動上完成,或者在每日站會後緊接著進行,趁著團隊每個人反正已經處於中斷狀態而且都在場。


為什麼在Sprint計劃會上不要對產品待辦列表項進行估算?
在Sprint計劃會議開始時估算產品待辦項目聽起來像是個好主意,但是,這會有兩個大問題。首先,這時候才考慮估算值來調整優先級對於產品負責人來說太晚了。

請記住,團隊完全估算其產品待辦列表項的原因之一,是使產品所有者可以確定優先級。如果直到開始進行Sprint計劃之前都沒有給產品所有者提供估算值,那麼假設產品所有者在確定優先級時會充分考慮這些因素是不現實的。其次,在Sprint計劃會議開始後估算產品待辦列表項的團隊往往在估算上會花費更長的時間。

我想這是因為團隊成員即將要進行更詳細的Sprint計劃,在這個想法的潛移默化下,通常會在對產品待辦列表項進行估算的時候引入更多的細節,這就使得,相對於我所設定的每3-4分鐘估算一個產品待辦列表項的目標,團隊要花費更長的時間。基於這些原因,請試著在Sprint計劃會之外去估算那些新的產品待辦列表項,並且還要在Sprint中盡可能晚的時間點,在大部分新的用戶故事(如果不能全部的話)已經確定之後。


是否所有團隊都應該估算?
這些論點不一定適用於每個敏捷團隊,但以描述充分理由,可以參考以上說明,再考量自身團隊是否適合去做產品待辦列表和Sprint待辦列表的估算。

台灣產業防疫未來

2020年第一季,我們一同開啟了另一個新的10年,卻也壟罩在2019新型冠狀病毒疾病(COVID-19,新冠肺炎)大規模流行的陰霾中...
台灣產業防疫未來
UPerform優普豐敏捷學院
國際Scrum Alliance聯盟REP及Agile Alliance聯盟企業會員、敏捷運動的推動團隊。創立於2007年,目前是華語地區擁有Scrum聯盟認證體系導師級Scrum認證者CST/CTC最多的機構,此團隊翻譯和撰寫了多本著作。
您可能也喜歡這些文章