會議目的
•該會議的工作以分析為主，目的是要詳細理解終端使用者到底要什麼，產品開發團隊可以從該會議中詳細瞭解終端使用者的真實需要。在會議的結束，團隊將會決定他們能夠交付哪些東西。
•產品負責人在會前準備：條目化的需求（使用者故事），優先順序排序，最近1~2個迭代最希望看到的功能。會前準備至關重要，可幫助產品負責人理清頭緒，不至於在迭代期內頻繁提出變更、增加或刪除故事。

基本要求
•迭代計劃會在每個迭代第一天召開，目的是選擇和估算本次迭代的工作項。
•只有團隊成員才能決定團隊在當前 Sprint 中能夠領取多少個 Backlog 條目的工作。

構成部分：
•經過估算和排序的 Product Backlog。
•掛圖、馬克筆、剪刀、膠水、即時貼、白板、鉛筆和蠟筆。
•假期計劃表、重要人員的詳細聯絡資訊。
•參會成員：團隊成員、Scrum Master、產品負責人

持續時間：在 Sprint 中，每週該會議佔用時間為 60 分鐘，在早上召開該會議，這樣還有可能在同一天召開 Sprint 規劃會議的第二部分。

會議輸出
•選擇好的 Product Backlog 條目。
•各個 Backlog 條目的需求。
•各個 Backlog 條目的使用者驗收測試。

會議過程
•從第一個 Product Backlog 條目（故事）開始。
•討論該 Product Backlog 條目，以深入理解。
•分析、明確使用者驗收測試。
•找到非功能性需求（效能、穩定性...）
•找到驗收條件。
•弄清楚需要“完成”到何種水平。
•獲得 Backlog 條目各個方面的清晰瞭解。
•繪製出所需交付物的相關圖表，包括流程圖、UML圖、手繪草圖、螢幕 UI 設計等。
•回到步驟1，選取下一個 Backlog 條目。

流程檢查：詢問團隊能否快速回答下列問題，只需要簡要回答即可：“我們能在這個 Sprint 中完成第一個 Backlog 條目嗎？”如果能得到肯定的回答，那麼繼續詢問下一個 Backlog 條目，一直到已經分析完的最後一個 Backlog 條目。——接下來，休息一下。在休息後，對下一個 Backlog 條目展開上述流程。

結束流程：
•在 Sprint 規劃會議第一部分結束前留出 20 分鐘。
•再次提問——這次要更加嚴肅、正式：“你們能否完成第一個 Backlog 條目，...第二個，...？”
•如果團隊認為他們不能再接受更多的 Backlog 條目，那就停下來。
•現在是非常重要的一步：送走 Product Owner，除了團隊和 Scrum Master 之外的所有人，都得離開。
•當其他人都離開後，再詢問團隊：“說真的——你們相信自己可以完成這個列表？”
•希望團隊現在能短暫討論一下，看看他們到底認為自己能完成多少工作。
•將結果與 Product Owner 和終端使用者溝通。

注意事項：不要改變 Backlog 條目大小，不要估算任務。