沖刺計劃會議 (Sprint Planning Meeting)
會議舉行時間
沖刺周期開始當天的早上（可以取代當日站會）
會議時間
每周工作量伴隨1小時的沖刺計劃會議，如果團隊每兩周沖刺一次，沖刺計劃會議就應該是2小時長
會議參與人
Product Owner，Scrum Master，全體項目成員，請Master在合適時間主動發出會議邀請
目標
讓開發團隊了解開發任務，分析與預估用戶故事難易度，并決定接下來沖刺要完成的工作項

Scrum Master分享桌面，將上次沖刺回顧會議制定出來的改善項目與整個團隊過一遍，確保團隊在這一次沖刺當中改進了上次列出來的改善項
Product Owner分享桌面，從Backlog中第一個任務開始跟團隊簡易介紹任務內容，介紹完畢后留60秒的時間讓團隊開放討論為了實現這個用戶故事需要設立多少子任務，然后給10秒鐘的時間讓團隊成員給出故事點預估
在兩個小時內盡可能多的預估任務
Scrum Master分享桌面，設置新的Sprint，根據團隊的平均速度(Velocity)，將等同120%團隊速度的任務從最高優先級，按照一定比例，在用戶故事都已完善并且有驗收條件的前提之下，開始拖拉到沖刺Backlog當中，并用一句話簡單描述沖刺目標，確保團隊成員都認同目標后，開始沖刺。

120%原則
例如團隊的平均速度是60點，我們會在沖刺中安排72點的工作量，這是為了避免團隊提早做完沖刺中的任務而發生無事可做的窘境。
任務分配Backlog中的任務一般可以分成三種類別，

技術債（Technical Debt）：為了加速開發流程，工程師往往會在應采取最佳方案時做了妥協，采用了短期內可以加速開發流程的作法，但長遠來看會成為遲早要填的坑，這種東西就叫技術債。常見的技術債諸如"缺乏文檔"，“缺乏測試方案”，“沒有按照標準流程做事情”，“因為項目時程緊張所以很多沒做但應該做的事情”，“需求本身沒有考慮技術實現問題而挖的坑"等等，這都是團隊為了填坑自己給自己建的任務，因為一開始方便，后來遲早要還的觀念，才稱之為"債”。
故障（Bugs）：由終端用戶或是QA工程師在測試過程當中發現的Bug，會以故障的形式記錄在Backlog中，等待開發團隊安排時間完成的任務。
新功能（New Features）：由Product Owner直接安插進Product Backlog的用戶故事，一般都是新功能需求，這些新功能需求直接對客戶輸出了價值，是三種任務當中客戶最想要的。

一般建議在每一次的沖刺當中，我們應該安排7成任務實現新功能，3成任務修復Bug與填坑。

總結

以上是生活随笔為你收集整理的冲刺计划会议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。