用戶故事時間老是估不準?三大技巧助你敏捷團隊一臂之力!


    「老師,我們公司有在使用敏捷方法做專案,可是團隊在估算用戶故事(User Story)時間的時候,老是估不準,有的時候會多留很多 buffer,有時候又少估很多時間,導致衝刺的工作做不完,這該怎麼辦才好?」 

    我在《Scrum 敏捷方法裡,渾然天成的九大風險管理把關設計》一文中談過,敏捷方法的框架其實隱含了不少巧妙的風險管控設計,其中當然包含了管控「因時間錯估而延誤」的風險。這裡我們先假設,這位學員提及的敏捷團隊,有確實遵守敏捷方法要求的原則來運作,沒有自行偷斤減兩,可是團隊對於時間的估算,卻依然不夠準確。在這樣的前提背景下,我們還有什麼其他的招數,可以來改善這樣的問題。 

    【比較法】的問題 

    假設團隊使用的規劃撲克牌是依據費式序列設計的,若有個用戶故事A,開發團隊估算其所需的時間為1點,接著將另一個用戶故事B與A做比較,認為B所需的時間大約是A的 1.5倍左右,所以開發團隊便將B的時間估為2點。 

    開發團隊繼續將另一個用戶故事C與B做比較,認為C所需的時間大約是B的2倍出頭,可是因為規劃撲克牌內並沒有4點的撲克牌可選,所以開發團隊便將B用戶故事的時間估為5點。 

    您可能已經發現,C用戶故事的點數可能已經在無意之間被過度放大了。如果我們繼續用這樣的做法來估算其他用戶故事的時間,那麼,愈晚被估算的用戶故事,它的時間可能就愈不可靠,誤差愈大。 

    上例中,用戶故事C的時間點數,其實是A3倍,也就是3點,可是因為選擇了不當的比較基準B,才造成了C被誤判為5點,那到底我們應該選擇A還是B,來當作C的比較基準呢? 

    也許您會這樣認為:把CB比較一次,再繼續把CA比較一次,接著把兩次的比較結果權衡一下,這不就得了嗎? 

    這樣做的確會比較準確,可是你試想一下,如果現在要處理第Z個用戶故事,而你已經有 25 個已經估算完畢的用戶故事,你和你的開發團隊會把Z和這 25 個用戶故事都像這樣一一比較一次嗎? 

    當然不會!因為這樣的做法實在是太沒有效率、太慢了。敏捷方法之所以要求時間的估算要使用「比較法」,就是因為有「大量」的用戶故事要估算,所以得夠「快」,而且還要得夠「準」。那麼,我們到底還有什麼做法,可以兼顧效率和準確呢? 

    (一)三角測量Triangulating) 

    被估算完點數的用戶故事,其實都可以當成我們的「比較基準資料庫」,理論上,資料庫內的任何一筆資料,都應該可以被我們當作估算下個新用戶故事時間時的比較基準。可是上述的例子告訴我們,這個資料庫當中的數據,有可能自己本身就已經不夠準確。故我們的首要之務,就是先想辦法建立一個「足夠準確」的「比較基準資料庫」。 

    當「比較基準資料庫」有足夠的數據後,我們在估算一個新用戶故事時間的時候,就應該在資料庫裡挑選出「兩個」用戶故事來當作比較基準,其中一個的點數要「略大於」新用戶故事,而另外一個的點數則必需「略小於」新用戶故事,如此把新用戶故事包夾在兩個基準之間來做兩兩比較,以確認我們對新用戶故事的點數估算是否有失真,這樣的作法就叫做「三角測量法」。 

    這樣做有三個好處:

    1. 對於新用戶故事的時間估算,不再像上例那般,只有單方向的比較(往大或是往小),造成誤差愈滾愈大。
    2. 透過這樣的方法所建立起來的「比較基準資料庫」會更加精準可靠。
    3. 對於新用戶故事的時間估算,速度會夠快。

    到這裡,您可能會以為,這樣就已經足夠了。其實,我們還可以做得更好!

    (二)隨機選擇 

    人,總有自己的偏好,開發團隊也不例外。於是,「比較基準資料庫」內的某些數據,總是會比較頻繁地被選來使用,而其他的數據則可能被長期冷凍,乏人問津,而這樣的主觀選擇,就容易造成估算上的不可靠。 

    因此,在遵循「三角測量法」的前提之下,當我們在選取比較基準時,除了考量基準和待估算用戶故事之間的「相似度」之外,最好也能「隨機」一些,讓基準的選擇能夠更加客觀。 

    到這裡,您覺得,做到這樣總該夠了吧?錯!我們還可以做得更好! 

    (三)與時俱進 

    首先,「比較基準資料庫」內的用戶故事,有些尚未被實作完成,其時間還只是個估算,而有些則已經完工,其時間估算就可以被驗證。如果這些已完工的用戶故事被證實,其當初的時間估算很不準確,那麼,這樣的用戶故事就不再合適被當做比較基準,應該從「比較基準資料庫」當中將之剔除。 

    其次,隨著時間的推進,「比較基準資料庫」內的某些用戶故事,其使用的技術也可能早已過時淘汰,該用戶故事也不再適合被當作基準來使用,也該從「比較基準資料庫」中將之剔除。 

    第三,開發團隊成員也可能會異動,也許會形成新人多過舊人的狀況,如果「比較基準資料庫」內的某些用戶故事,對多數開發團隊成員來說是陌生的,那麼,這樣的用戶故事也不適合再繼續被當做比較基準,也該從「比較基準資料庫」中將之剔除。 

    最後,假若開發團隊成員沒有太大變化,「比較基準資料庫」內的用戶故事所用的技術也沒過時,我們就不必持續更新「比較基準資料庫」了嗎?答案當然是,「要持續更新!」為什麼呢? 

    因為,即便開發團隊成員和所用技術都沒太大變化,人的記憶總是有限的,對於那些歷史悠久的用戶故事,開發團隊當初是如何考量才做出那樣估算的記憶,往往早已模糊失落。在這樣的情況下,要繼續使用這些陳舊的用戶故事當作基準來跟新用戶故事做比較,往往更容易造成估算的失真。因此,這類過於陳舊的用戶故事也不適合繼續當做比較基準,也該從「比較基準資料庫」中將之剔除。

     

    經過以上這些多面向的技巧把關之後,相信您和您的開發團隊,對於用戶故事的時間估算,肯定會更加地得心應手才是。


    圖片來源:pixabay.com

    相關文章

    非軟體產業也能掌握的敏捷式團隊工作術公開班報名

    《EZ敏捷專案管理》兩日班課程簡章

    敏捷方法的成功密技》系列文章總覽