症狀 (Symptom)
喜歡用公式換算，像是點數換算時數，時數換算點數，換算可完成的 story 數量，點數換時程等等。
討論 (Discussion)
分享兩個故事，第一個是我在水果公司的第二年，當時 Android 團隊剛開始起步，那時團隊成員剛組成，少數人對 Scrum 的認知不是很清楚 (有一半以上的人過去有 Scrum 經驗)，所以那時 planning 是先把可工作日乘平均實際工作時數，減去會議時間後再乘上人數得到的總時數，作為 story 是否能排進這個 sprint 的參考，planning meeting 後排進的 task 總時數接近上限。即便如此，回頭看 burn-down chart，task 時數預估其實很少有準過，但消化的 story 數卻有逐漸穩定的趨勢。
第二個是我後來的另一家公司，當時已經跑了四個 sprint 的 Scrum team 突然加了兩個人，然後開發的東西完全換了 (使用的技術和語言都和前一個不同)，團隊更動後的第一個 sprint，planning 時使用的方式是用信心指數，也就是 task 切完後，Scrum Master (不是我) 從 priority 高的 story 開始問團隊成員：這個 story 排進去有信心完成嗎？一直到團隊成員沒信心為止，當時 planning 完後總 story 數好像是 26 點，task 總時數是印象中不到 100 小時。某天管理層問 Scrum Master：團隊有六人，兩個禮拜的 sprint 為什麼只有不到 100 小時的 tasks？後來那個 sprint 實際完成的 story 數是 31 點，因為在結束前兩天，又拉了一個 5 點的 story 進來，實際的 task 總 (預估) 時數印象中也才一百出頭。在我離開前，團隊消化的 story 數也趨近一個穩定值。我不確定看完兩個故事後，大家的感想是什麼？第二個故事裡的團隊很混？事實上，我在上面故事裡有一些沒提到的事情，第一個故事裡，接近 sprint review 的前幾天，團隊的下班時間通常也越晚。第二個故事裡，由於新的工作內容是延續加入的那兩位成員的工作，對使用的技術和語言熟悉的人數比是熟悉 2，對上不熟悉 4，估時的時候，時數常會被熟悉的人牽著鼻子走，但實際執行時，不可能所有的 task 都是熟悉的人施工，因此預估值和實際值的差異時常很大，這也是我當初和 Scrum Master 討論用信心指數決定數量的一個原因。
第二個故事還有後續，當時和 Scrum Master 向公司的顧問提到此事，顧問笑著說，很簡單啊！直接把時數乘上一個倍數，塞滿預估值就好啦！重點是讓管理層相信團隊，如果把預估值塞滿能讓管理層相信團隊有好好地做預估，那就把它塞滿，只要 sprint 結束時能有高品質的產出，而且產能是可被接受的，管理層就不會在意這個預估值是被乘上任意數的結果。我能理解這是權宜之計，但心中總是不那麼踏實，所以，後續的 sprint 我們並沒有真的這樣做，之後 可能因為大家慢慢熟悉技術和語言，點數也成長到四十幾左右，至於預估的總時數呢？這就是有趣的地方了，不知道是生性樂觀還是什麼原因，其實很少會超過 100。
基本上，這陷入了一個換算的盲點：就像是氣象預報，預估終究是預估。如果工作的預估和實際的執行是一致的，就不會有《人月神話》中那一句話：用人月的前提必須是人力與工時可以互換的情況下。我並不是說反正執行結果都不會跟預估的一樣，所以團隊成員在 planning meeting 裡可以亂估，而是要回頭想一下，Scrum 裡 planning meeting 的本質是什麼？是在尋找團隊對 story 及 task 的內容取得共識，以及對這個 sprint 能完成哪些項目進行預報，時數和點數只是用來做預報的參考，這也是為什麼大多數都建議 story 用相對的點數進行預估，而不是用容易被誤解的時數。
那時寫完這篇文章時，考慮到文中不少當事人都還是同事，也就沒有發布了，如今文中的當事人都各奔東西，那時的團隊也都不見了，我想應該是可以發布，算是為過去的工作經驗留點紀念吧。
回到目錄：Scrum Bad Smells
