Sprint Planning是Sprint開始時的一個時間盒事件，Scrum團隊在這里共同合作，確定可以做什麼以及如何在Sprint中完成工作:
1. Sprint可以做什麼
2. 選擇的工作將如何完成？
Part 1. Sprint可以做些什麼？
在 Part 1，產品負責人指出了Sprint背後的意圖，目標和Scrum團隊合作以理解工作。只有開發團隊可以選擇他們將在Sprint期間處理的項目數量，並且他們是唯一可以確定將多少工作帶入Sprint的人。Scrum團隊共同合作形成Sprint目標 (Sprint Goal)，描述Sprint的意圖和定位，以及為什麼他們正在為Sprint工作。（Scrum指南也將此稱為為工作提供“連貫性”。）
實用技巧
衝刺位置 | 提前了解產品負責人對Sprint的目標和戰略定位有助於減少對Topic One的影響，並消除對產品的高層次思考。 |
Sprint目標 | 為產品負責人提供關於“為什麼”Sprint目標很重要的上下文可以幫助開發團隊改進他們對Sprint選擇的項目的選擇。 這可能是閃電話語，音調，草圖或其他有助於理解目標的意圖和需求的信息。 |
容量 | 參考之前的Sprint容量將有助於開發團隊了解為其能力範圍內的Sprint選擇的工作量 |
路線圖和願景 | 長期高水平的願景或路線圖可以幫助產品負責人進行戰略性思考，並幫助開發團隊將Sprint與產品保持一致 |
衝刺目標 | 精心設計的Sprint目標為開發團隊開展Sprint工作提供了理由和背景，可以幫助他們在選擇Sprint項目時橫向思考，並提供一些真正的重點。 |
Part 2. 選擇的工作將如何完成？
Part 2 - 圍繞自組織開發團隊以及他們在Sprint期間如何完成工作的決策。在Part I - 中選擇的項目和提供它們的計劃稱為Sprint Backlog。如果開發團隊確定他們對Sprint的工作太多或太少，則可以與產品負責人重新協商所選項目並進行調整。在主題和Sprint計劃活動結束時，開發團隊應該能夠清楚地闡明他們在Sprint期間如何協同工作以交付項目並創建增量。
實用技巧
能見度 | 使用Sprint Backlog的可視化任務板或類似工具非常適合那些能夠清楚地看到他們決定在Sprint上工作並在Sprint中維護它的團隊，以提供當前工作狀態的可見表示。 使工作高度可見，可以在團隊內部進行更深入的決策。 |
項目和任務 | 有些團隊喜歡使用單層系統來跟踪他們在Sprint Backlog上的項目，但是，這些項目應該足夠小，以至於它們處於粒度級別，然後最多可以在幾天內輕鬆完成。 其他發現難以將項目拆分為小項目的團隊可能會選擇使用（父）項和（子）項任務組合的2層系統來完成它們，從而為團隊提供更精細的粒度。並且很容易完成。 |
測試結果 | 考慮到要實現的測試目標，以及當開發團隊處理項目時要回答的問題可以真正幫助將它們分解為更小的可測試項目，即使它們屬於更大的構造或框架。 |
自組織 | 允許開發團隊在選擇要做的工作和如何做的時候真正自我組織將有助於有效地利用他們的經驗和知識為Sprint做出良好的戰術決策。 |
產品所有者可用性 | 讓產品負責人圍繞開發團隊提出問題並澄清事情可能對調整Sprint的組成並適當設置期望非常有幫助。 |
新東西 | 在Sprint計劃期間，可能適合創建不在產品Backlog上的新項目，但在Sprint中實現Sprint目標是有意義的。 |
估計 | 如果Scrum團隊正在使用規模估算和指標，那麼開發團隊可能適合重新估算項目並確定新項目的大小，以確保規模在工作開始之前反映當前的理解。 調整大小的常用技巧包括Planning Poker和Affinity Sizing。 |
調整 | 完成Sprint計劃活動後，整個Scrum團隊可以退後一步，查看Sprint Backlog，並為開發團隊提供機會，以便在需要時對其進行精細調整。 |
預測 不是承諾 | 在Sprint計劃活動結束時，開發團隊將對Sprint的工作進行預測。 隨著工作的完成，對工作的更深入理解開始展開，因此有可能需要調整和調整工作的組成，因為已知的更多。因此，將Sprint的工作構成視為“預測”而不是“承諾”更為恰當。 |
