【Scrum規劃會議】(三)進行Story Point的評分
Scrum規劃會議評估Story Point的流程是什麼?應該注意哪些事項?原理又為何?這次將帶你一一解析Story Point的奧秘!
為什麼要寫這篇文章？規劃會議中，我覺得步調最棒的就是評分的時刻，有足夠的速度感，而且能快速溝通很多事。Story想了那麼多，能不能執行、大家思考是否一致，只要一評分就可以馬上知道結果。而評分的流程雖然簡單卻富含哲理，這次想介紹的是SCRUM規劃會議的Story Point細節。讀完這篇你會知道什麼?1.如何用Story Point衡量工作速度
2.評分的簡單流程
3.評分的前提與注意事項
2022.03 更新版請點此：(三)如何評估工作量與共識程度
參考最新版的Scrum手冊，修正一些觀念與描述用詞，希望大家會喜歡。
SCRUM規劃會議，Story Point的目的：衡量速度
團隊使用SCRUM工作法，就是為了
「做得比以前快」
但該如何證明「真的做得比以前快了？」這就要用到規劃會議所規劃出的「Story Point」。
Story Point代表：事情的「時間規模」
每個Sprint可能會有數十個Story，而每個Story都會有屬於它的Story Point，用以衡量單一任務的「時間規模」。
時間規模的評估，包含了這有「繁雜度」、「關聯人數」、「熟悉程度」、「難易度」、「基本作業時間」等因素。通常只要越複雜、涉及人越多、越不熟悉…所花費的時間就會越多。
而既然是衡量「時間規模」，當然就「不包含」完成事情所帶來的價值、需要花費的金錢等等。
怎麼用Story Point衡量進步？
既然SCRUM的目的是「做得比以前快」，另外一層意義，就是比之前還要進步，因此必須跨Sprint來掌握進步狀況。
例如，團隊在Sprint 1做了10個Story，所得到的分數是100；Sprint 2 做了12個Story，所得到的分數是150。
我們會以分數來衡量進步。當這2個Sprint做事情所花費的總時數一樣，那就代表大家進步了50%。
但因為我們公司的人數、Sprint週期都時常變化，為了呈現正確的進步狀況，我常使用「得分效率 (Story point / hour)」作為團隊績效的指標。
也就是計算每小時，整個團隊可以得到幾分。
．
例如，Sprint 1的全體成員的總工作時數是360 hr，然而Sprint 2因為新增成員的緣故，總時數變成 432 hr。
這樣算下來
Sprint 1 的得分效率 =100/360=0.28 (Story point / hour)
Sprint 2 的得分效率 =150/432=0.35 (Story point / hour)
以得分效率來看，進步幅度就會變成25% ((0.35–0.28)/ 0.28)。
用得分效率來評估，主要是因為人少、時間短時，會讓數字差距放大，但如果變成比例的話，能更正確反應進步狀況。
怎麼用Story Point衡量速度？
所有的專案管理都會面臨到評估進度的困難：
現在事情完成度多少？
進度落後多少？
還有幾天會完成呢？
在一般專案管理上，這一直都很難解。也才會有甘特圖完全不準，剩下10%的工作永遠做得最久。
在SCRUM的專案管理中，用了兩個特點來避免走上這條道路：
「專注、可估計」
在SCRUM工作原則中，應該盡可能先完成一件事情，再開始下一件事。而每一個任務都有明確的方法、流程，是可以用「小時」來估計的任務單位。
既然，事情必須一件一件做、時間都要可以預估，那要在過程中評估現在的執行狀況就相對容易一點。
只要把「已工作時數 x 上一次得分效率」，就可以算出目前預期、至少要有怎樣的進度。
例如，Sprint 2已經來到第3天，PO就可以這樣計算：
已工作時數=3(天)x8(人)x6(小時)=144 hr
Sprint 1 得分效率 0.28> 目前應得分數：144 x 0.28 = 40
如果跟上一次Sprint比較，團隊就算沒有進步，也至少要得到40分，如果分數不到40分，很可能代表現在遇到了不少困難，導致進度落後。也可能是大家做的事情過於分散，需要再重新聚焦。
※為什麼如果不是一件一件做，就會發生速度難以評估的狀況?我們來假設一個情境：Sprint 1的前3天，團隊同時開始了10個Story，在第4天一共完成3個，獲得15分；
Sprint 2的前3天，團隊同時開始了15個Story，在第4天一共完成2個，獲得8分。很明顯，我們沒辦法在第四天時評估，到底是哪一個Sprint比較有效率，因為Sprint 2落後的7分，可能是因為同時多做了5個Story。(當然也可能不是，但我們得在完成Story後才有辦法評估)而如果用SCRUM工作法，是一個一個Story來做，在第4天時，手邊一定有1個正在做的Story，獲得的分數就能更正確反應速度。換句話說，同時進行的任務越少，衡量速度就能越準確。
燃盡圖Burndown Chart的使用
很多敏捷工作都會用到燃盡圖，但我後來發現不太適合我們的團隊，因為我們的Sprint期是2周，扣掉假日的時間，根本沒辦法跑出視覺上看得出差異的圖表。
不過，Burndown用來比較每次Sprint的其實是不錯的，有的時候會一開始很快，有的時候會遲遲無法完成Story。當然最理想的燃盡圖狀態就是跟著平均線走。這才代表團隊是專心地先做一個Story，才開始下一個Story。
規劃會議怎麼進行Story Point評分？
說了分數的用意後，接著就要來說說，到底規劃會議要怎麼評出Story Point。以及它的原則與細節又是什麼。
用「費氏數列」評估「時間規模」
在SCRUM中，Story Point是用來評估「時間規模」的，因為在SCRUM理論中有提到一點：
「人們其實不太有能力，去估計大任務所需要的時間」
例如，你可以輕鬆地評估吃一餐所需要的時間，但如果要評估1個月吃飯所花費的時間，就顯得困難許多。
況且，我們沒那麼多時間，在一切都還沒決定前，就精密地計算數十個任務的時間，因為這樣會大大降低決策效率。而且大專案的精密計算的結果，也往往跟實際相去甚遠。
但要如何在還沒做、還沒規劃以前就知道「大概花多少時間」呢？
為了快速知道「大概花多少時間」，SCRUM發展了一套評分機制，讓大家用「感覺」來評估事情所花費的時間。
．
SCRUM引用了「費氏數列」估來算各項Story 的分數。也就是每個Story Point都只會是： 1 、2 、3 、5 、8 、13 、21 這幾個數字。
Point越小，代表這個Story花費時間越少；越大，就代表花費時間越多。
前面一直提到，Story Point是評估「時間規模」而不是「時間」，原因就在這裡：
雖然我們沒能力準確估計時間，但如果單純比較規模大小的話，就擅長許多，而且也可以在不用太仔細思考、計算的狀態下，給出比較準的答案。
「費氏數列」所造成的級距差異，是由小到大，也剛好可以符合事情越大，我們就越會估不准的情境。因此它直接幫我們把大的任務放得更大。
．
值得一提的是，如果評出了一個21分的Story Point，很可能就代表這個Story實在太大了，在這次的Sprint中無法完成。此時，我們就得忍痛刪除它，並切分成更小的任務才行再來重新評分才行。
Story Point評分的簡易流程
評分其實就像簡單的舉手投票。我們公司的流程是這樣的
- 先說完全部的Story (目標、方法、Criteria…)
也就是規劃會議一開始應該提到的內容。 - 設立判斷標準，縮小評分差異
所謂的基礎標準，就是先用兩三個Story讓大家有個共識。你認為的5分Story，可能我認為13分。大家都有一個自己的感覺，但在評分之前，可以先把你的5分和我的13分都調整成團隊的5分。如此就可以縮小評分上的認知差異。 - 各自在表單上寫下評分
大家看著Story列表，直接輸入1~21的費氏數字。過程完全不講話、不討論、不提問。每個人都投完所有Story的分數之後，才開始討論。
(如果有問題，就填寫「?」或「21」，因為共同評分就是為了讓對Story有問題的人被凸顯，如果有問題還要先問，就等於多此一舉了) - 針對差異太大、無法評估的Story進行討論
究竟要討論那些Story呢？
討論Story，一般而言只討論兩種：
- 差距3個費氏級距以上的Story
- 有人投21分的Story
例如，如果同一個Story有人評1分，有人評5分，就差了3個級距，數字最小和最大的人就要說明，為什麼認為這個時間規模是1，為什麼這個會是5。
只討論這兩者的原因是：
只有當級距夠大，才代表我們對於規模的認知真的差太多了，才會造成事情做錯，如果差距不大，就沒什麼差別。
我們評估Story規模時，不是在比較一粒芝麻和兩粒芝麻的差異。是在比較一粒芝麻、一顆蘋果、一顆西瓜之間的差異。只有在你認為事情是芝麻大小、我認為是西瓜時，才有必要來討論。否則其實也不會差太多。
另外，每當出現21分就要討論Story，是因為前面提到的，這個Story很可能太大，需要做切分。
．
分數差異的原因五花八門，包含對任務的認知、解法、熟悉度等等。
例如，同樣在一個展覽會場擺放100張椅子，經驗老到的老鳥，可以快速擺放完成。菜鳥還需要先畫擺放圖，在思考動線等等，就造成評估上的差異。
但還是要強調，我們只想比較差異足夠大的事情，如果不夠大，頂多就是1小時和5小時任務的差別。
透過投票，我們想抓出的是「有沒有一個1小時事情，有人認為需要做到50小時。」如果有，就代表大家對這事情沒有達成足夠共識，做出來的東西可能會差異巨大。
至於討論的內容，其實就只是把Story再重新說明一次、換句話說而已。並不是重新寫新的Story、更改目標、Criteria。（因為這是精煉議該做的事）
什麼情況才能進行Story Point評分？
1. 寫好Story，才有辦法評分
我們公司一開始跑SCRUM時，最常發生一堆人評分是「？」或是「21」。也有許多級距超過3的情況，基本上有1/3左右的Story是沒有共識的。
但其實這不是討論、說明就能解決的，常是Story沒寫好的關係，定義不清、過於龐大，都會讓人無法評分。(所以我才會花如此多篇幅，說明要如何寫出好的Story)
不過，這樣的狀況也代表這個評分制度是良好的，因為在什麼事情都還沒開始做的時候，就能用評分知道，這個Story沒有規劃好、我們沒有共識、需要更多討論才可以開始做。可以省掉許多做錯、做歪、多做的時間。
※延伸閱讀>>【Scrum規劃會議】(一)先說好目標與Story
>>【Scrum規劃會議】(二)說好Stroy的KPI與Criteria
2. 你瞭解、可能是你做，才可以評分
有的時候，團隊包含各種專業人才，但彼此之間未必能互相幫助，甚至會完全不懂其他人在做什麼。此時，如果你不需要做、沒有能力評分，那就不用評分了，不然只會造成混亂。
因為這種團隊與SCRUM團隊有所落差，當然有部分流程就不能用原本的方式進行。如果有這種情況，你可以把這些Story視為另一個Team的Story，基本上與你無關，只是為了方便、溝通，所以大家一起開會而已。
Story Point評完之後呢？
評完分數，幾乎就代表Sprint旅程的開始了，當每一個Story都有分數之後，意義是非常重大的。
代表團隊的每個人，現在都清楚知道Story的目標、標準、大致做法、大致花費時間。
甚至如果PO現在離場，大家仍然可以開始行動。
是否要修改Story Point？
在執行的過程中，為了完成Story，可能會進行做法上的調整，也會有3分的Story做13小時，13分的Story做3小時的情況。
不少人一定曾因此疑惑
「要不要在執行Sprint期間或結束後修改Story Point？」
我個人是認為不需要，因為只要Story本身沒變，只有Task產生變化，芝麻還是芝麻、西瓜仍是西瓜，時間規模本質上不會改變，只是大家的認知上出現了些微誤會。
況且，如果某個任務比較常執行，即便這次錯誤估了，也能在下一次評分時給它比較對的分數。原本認為3分的事情，做了之後發現很複雜，就給投給它5分吧。久而久之，大家對於時間規模的估算，就會越來越準確。
Story Point評完後的宣布儀式
在評分完畢後，就可以把這次要做的任務列出來了，如果上一次做了100分，這次可以把目標設在150~200之間，把任務依照優先順序拉出來，PO就可以跟成員們說：
「這次的衝刺期為10天，我們將比上次進步約50%，總共有23個Story、一共150分的任務要完成。衝刺的目標，是希望讓我們網站的流量獲得10%左右的提升。」
宣布完後，就可以進入開發團隊寫Task的階段了！
※延伸閱讀>>【SCRUM工作術】文章總表
>>【Scrum規劃會議】(一)先說好目標與Story
>>【Scrum規劃會議】(二)說好Stroy的KPI與Criteria
>>【Scrum規劃會議】(四)撰寫Task與回顧檢驗．如果你喜歡我的文章，歡迎給我拍拍手~「1下」拍手：到此一遊，留個記錄吧。
「5下」拍手：表示喜歡這篇文章。
「15下」拍手：表示你想要知道更多相關的內容！
「30下」拍手：手應該會有點痛，但還是歡迎繼續拍。按下「訂閱內容」，將能定期收到優質的文章、免費資源！
