什麼是Sprint規劃？
Sprint規劃是scrum中用來啓動Sprint的事件。迭代規劃的目標是定義Sprint能夠交付的內容，以及如何完成各項工做。迭代規劃須要整個scrum團隊合做完成。markdown
與體育概念中的最後衝刺不一樣，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規劃作準備，還能夠爲評估當前的工做提供不一樣的視角。blog
限制Sprint規劃的時間
Sprint規劃的時長應限制在每週兩小時之內。因此，一個爲期兩週的Sprint，其規劃會議將不會超過兩個小時。這叫作「timeboxing」，即設定團隊完成一項任務所需的最長時間，在這個前提下，進行Sprint規劃。Scrum Master負責確保會議在規定時間內完成。若是團隊在限定時間內達到了滿意的效果，就能夠認爲會議順利完成。時間限制僅強調最長時間，對最短期沒有限制。事件
專家提示：
將Sprint目標做爲Sprint規劃的重點，不要將過多的精力放在Backlog的細節上。 聚焦目標而非具體的工做，才能讓團隊有更多的精力找到實現目標的最佳方案。開發
聚焦結果而非具體工做
在作Sprint規劃時，團隊很容易陷入「細節困境」，糾結於哪一個任務應該先作，由誰作，以及完成這項任務須要多少時間等。對於比較複雜的工做，初期掌握的信息有限，且大部分判斷都是基於假設。Scrum是一個徹底根據經驗的過程，這就意味着不少工做沒辦法提早規劃，而是要經過實踐來學習，而後將學習到的信息反饋到整個開發流程中。
Sprint目標以一個比較高的水平對Sprint的目標進行闡述，而backlog列表也能夠用結果導向的思惟來編寫。用戶故事是一種從用戶角度描述工做的很是好的方式。以下圖所示，用戶故事應該將焦點放在客戶最終想要實現的效果的缺陷、問題和改進上，而非觀察到的問題。get
經過在用戶故事中添加清晰、可測量的結果，團隊能夠清楚地衡量輸出結果，知道何時纔算完成。儘量提早了解團隊聚焦的工做，這樣團隊中每一個人在啓動工做時就不至於一無所知。例如，團隊能夠將沒法肯定的事情定爲須要在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敏捷博客