什麼是Sprint規劃？
Sprint規劃是scrum中用來啟動Sprint的事件。迭代規劃的目標是定義Sprint可以交付的內容，以及如何完成各項工作。迭代規劃需要整個scrum團隊合作完成。
與體育概念中的最後衝刺不同，scrum中的‘衝刺’（sprint）要求團隊一直保持極速狀態以提供可工作的軟件，與此同時還需要不斷學習和提高。
在scrum中，Sprint是所有工作都得以完成的一段時間。只是在開始行動前，需要設置Sprint的相關條件：例如要決定時間週期的長度、Sprint目標以及從何處開始行動。Sprint規劃會圍繞Sprint中的應辦事項和工作重點展開。如果組織得當，Sprint規劃會還能夠為團隊營造一個充滿激情和挑戰並指引團隊走向成功的環境。糟糕的Sprint規劃可能會因為設定不切實際的目標，而導致團隊的失敗。
- 做什麼——Product Owner闡述Sprint目標以及對實現目標有益的PBI。Scrum團隊據此決定在即將開始的Sprint中需要做什麼，以及要做哪些才能實現Sprint目標。
- 怎樣做——開發團隊根據需要交付的Sprint目標來規劃具體工作。經開發團隊和Product Owner協商一致後，最終得到一個基於價值和工作量的Sprint計劃。
- 誰來做——Sprint規劃必須要有Product Owner和開發團隊的參與。Product Owner根據產品的價值取向來制定Sprint目標。而開發團隊則需要弄清楚能否實現該目標。二者都必須參與，缺一不可，任何一方的缺席都將導致Sprint計劃無法進行。
- 輸入——Product Backlog是Sprint計劃中非常重要的一個出發點，因為它提供了可能會成為當前Sprint一部分的“基本特徵”表。除此之外，團隊還需要查看增量中已完成的工作，以瞭解進度和剩餘工作量。
- 輸出——Sprint規劃會議最重要的目的是讓團隊闡述Sprint目標，以及如何實現這個目標。這些內容將體現在Sprint的Backlog中。
Sprint規劃會的前期準備
要舉辦一場精彩的Sprint規劃會需要滿足一些基本要求。Product Owner要做好充足的準備，結合前一次的Sprint Review會議中總結的經驗教訓、利益相關者的反饋以及他們對產品的願景，奠定Sprint的基礎背景。透明度方面，Product Backlog應是更新後的版本，確保清晰精準。Backlog Refinement是scrum中一個可選事件，因為有些backlog不需要進行梳理優化的。但對大多數團隊而言，最好在sprint規劃會前將團隊聚在一起對backlog進行review並做出優化。
專家提示：
週期為2周的Sprint，要在中期舉行一次backlog梳理會議。跳出當前的Sprint來思考下一個對團隊來說大有裨益。這樣不僅能夠為Sprint規劃做準備，還可以為評估當前的工作提供不同的視角。
限制Sprint規劃的時間
Sprint規劃的時長應限制在每週兩小時以內。所以，一個為期兩週的Sprint，其規劃會議將不會超過兩個小時。這叫做“timeboxing”，即設定團隊完成一項任務所需的最長時間，在這個前提下，進行Sprint規劃。Scrum Master負責確保會議在規定時間內完成。如果團隊在限定時間內達到了滿意的效果，就可以認為會議順利完成。時間限制僅強調最長時間，對最短時間沒有限制。
專家提示：
將Sprint目標作為Sprint規劃的重點，不要將過多的精力放在Backlog的細節上。 聚焦目標而非具體的工作，才能讓團隊有更多的精力找到實現目標的最佳方案。
聚焦結果而非具體工作
在做Sprint規劃時，團隊很容易陷入“細節困境”，糾結於哪個任務應該先做，由誰做，以及完成這項任務需要多少時間等。對於比較複雜的工作，初期掌握的信息有限，且大部分判斷都是基於假設。Scrum是一個完全根據經驗的過程，這就意味著很多工作沒辦法提前規劃，而是要通過實踐來學習，然後將學習到的信息反饋到整個開發流程中。
Sprint目標以一個比較高的水平對Sprint的目標進行闡述，而backlog列表也可以用結果導向的思維來編寫。用戶故事是一種從用戶角度描述工作的非常好的方式。如下圖所示，用戶故事應該將焦點放在客戶最終想要實現的效果的缺陷、問題和改進上，而非觀察到的問題。
通過在用戶故事中添加清晰、可測量的結果，團隊可以清楚地衡量輸出結果，知道什麼時候才算完成。儘可能提前瞭解團隊聚焦的工作，這樣團隊中每個人在啟動工作時就不至於一無所知。例如，團隊可以將無法確定的事情定為需要在Sprint期間回答的問題，也好過讓其保持不清不楚的狀態。專家提示：
無法確定某事和讓其保持不清不楚的狀態是兩回事。不要忽視未知事件，因為它們就是團隊必須腳踏實地完成的艱苦工作。但也不要使用含糊不清的描述來掩蓋或隱藏它們。相反，當你不瞭解某些事情時，要認清自己的無知，並將其列為需要進一步瞭解的工作。
預估是必要的，但不代表要假裝瞭解未知事項
Sprint規劃需要一定程度的預估。團隊需要明確Sprint中能或者不能完成的任務，即：預估工作量和實際工作量。工作量的預估經常與承諾相混淆。預估本質上是團隊根據當前掌握的知識做出的預測。衡量工作量大小的方法如故事點（story points）和T恤尺碼分類法（t-shirt sizing）分別為團隊提供了不同的視角來分析和看待問題。而它們並非神器，不能幫助團隊在尚未掌握足夠信息的前提下發現真相。因此，未知因素越多，預估的正確性就越低。
良好的預估要基於相互信任的環境，在這種環境下，團隊可以自由交換信息，在不斷的學習和改進中對假設進行論證。如果工作完成後證明前期的預估是錯誤的，那麼以後的預估要麼變得大很多，以確保不再出錯；要麼花更長的時間來進行預估，以避免再次出錯。
專家提示
團隊可以嘗試用不同的預估方法，如T恤尺碼分類法（t-shirt sizing）或故事點（story points）。因為不同的方法分析問題的角度不同。
Sprint規劃最佳實踐
Sprint規劃期間，團隊很容易陷入“細節困境”，導致他們忘了Sprint規劃的重點是為接下來的Sprint制定一個“恰到好處”的計劃。規劃不應成為團隊的負擔，而應該幫團隊專注於有價值的結果，並確保團隊保持正常的運行軌跡。好的Sprint規劃通過定義輸出的結果和清晰的計劃來獲得成功。但也要小心過猶不及，Sprint規劃中，要聚焦目標和恰到好處的Sprint Backlog，而不是面面俱到的規定Sprint中每一分鐘的工作計劃。接下來，就是確定Product Backlog的順序，以便團隊提前完成Sprint目標時能接著進入後續的工作中。
Scrum是一個旨在解決複雜問題的流程框架，而複雜問題的解決需要一個經驗積累的過程（即邊做邊學）。經驗積累的過程很難預先計劃，所以不要自欺欺人——要承認我們不可能制定完美的計劃。相反，可以專注於結果並投入到實際的工作中去，哪怕我們正在嘗試解決非常困難的問題，啟動工作仍可以是一件易事。
更多敏捷乾貨盡在公眾號「WorKtile研發中心」
現在關注即可免費領取電子書《2019研發績效》
P.s. 文中軟件示例來自“Worktile”
點擊下方“瞭解更多”前往官網註冊使用
↓↓↓
