Sprint planning meeting的目的是在於定義這次開發週期間共同所要追求的價值目標，為每一個使用者故事(User story)給予故事點數(Story point)，選擇合適的故事排入開發週期中，並將使用者故事在拆分成子任務，給予估時。這樣的流程，平凡又簡單，除了[Day21] Scrum失敗經驗談 – 沒有價值的User story 提到的沒有價值導向的使用者故事外，我們過去在各個環節犯了不少錯誤：

使用者故事在Sprint planning會議初登場

危機一：使用者故事沒有足夠時間可以迭代優化

在過去，使用者故事在sprint planning會議才和工程師相見不歡，這樣的行為代表，使用者故事的開立具備百分之兩百的信心，確信故事沒問題，故事完全符合INVEST原則，也考量過工程師的技術能力與可能性，對！完全是不可能的事情！完全沒有工程師意見input的使用者故事，是不可能順利進入sprint裡面的，雖然，我們後來有意識到這件事，將使用者故事提前到sprint review and retrospective會議，但還是遠遠不夠，當發現故事有問題的時候，是沒有足夠的時間修正使用者故事，最好的時間點，還是要在使用者故事誕生的時候，就要徵詢工程師意見，不論是固定的會議或是和工程師另約時間都好，當使用者故事大量不清楚的時候，就不要讓故事進入sprint之中。

估時後，緊接執行與排序

危機二：忽略「無法掌握事項」的風險

我們會利用費氏數列(1, 2, 3, 5, 8, 13, 21, …)來為使用者故事評估難易度，最早我們在估時的時候，給予故事點之後，就會緊接著開始分配任務，讓每一個工程師所取得的故事點加總相同，然後讓各自去拆解故事變成子任務，完美地棄風險而不顧。故事點是幫助我們了解難易度的一個量化管道，當故事點值很大的時候，就代表著需要被關注，依據我們要開發的項目與難度，我們團隊後來的共識是只要故事點大於13就需要被討論，故事點值很大代表的可能性有兩種：一種是故事描述不清楚或規模過大，這時候，就需要請PO處理，將故事釐清或再次確認規模是否可以再調整；另一種則是所需要採用的技術或做法已經超出當前工程團隊所能掌握的範圍，不管實際作法為何，但就要給予工程團隊Survey的時間，將不確定性下降，才有辦法將風險降到最低，如果時間很趕，就需要想個替代方案了。

未認真看待估時

危機三：未能將估時視為一把尺，找出方法提高準確度

「估時都是不準的」，「請問估時重要嗎？」講師那時下了一個宣稱(Statement)之後，問起了我們。答案當然是重要的，如同那時候講師接著往下說的，「否則為何我們要花時間討論估時這件事」。要讓估時不斷準確，有很多種的工具可以輔助我們觀察，但我在這裡要說的是看待估時的心態，不要將估時視為期限(deadline)，而是一把標尺，當估時視為是期限的時候，我們都會想盡辦法追求數字上面的符合，而忘記其實是要利用「經驗法則」更加掌握自己和掌握任務的核心意義，而這樣的心態，不單單是工程師要有，身為推動者或主管也要有，這樣團隊才能發揮估時真正的價值與意義，讓我們更能瞭解每一次開發的風險位於何處，而非只是看表面數字的完美。