短跑衝刺法(Sprting) 在 Scrum 開發方式中是一個很重要的活動，因為後續的開發活動都仰賴這個會議所產生的 sprint backlog。

在傳統的瀑布(Waterfall)開發方式中，當開發組員(Developers)拿到所謂的「分析設計文件」的時候，他們的腦袋中可能對於接下來要如何施工還是一片空白。

但在 Scrum 中由於有了Sprint Planning Meeting 這個活動方法，每個開發組員(Developers)去認領工作任務(Tasks)時其實對於要做什麼事情自己心中多多少少已經有了底（當然在實際施工的時候 還是有可能有問題產生），所以相較起來後續的施工問題會少很多。

Sprint Planning Meeting 作業概要
1)開始時間：
每個 sprint 開始的第一天舉辦此會議。

2)參加人員：
Product Owner、Scrum Master(組長兼任前述兩個職務)、Developers(專案組員)。

3)會議目的：
會議目的是產生一份 sprint backlog（包含每個 story 細分之後的施工項目）讓 Developers 可以開工。

4)進行方式（上半場）：
由 Product Owner 逐一詳細介紹這個 sprint 要施工的每一個 stories，並且與 Developers 互動，如果 Developers 對於 stories 內容不了解一定要發問。 介紹完之後 Developers 開始估計每一個 story 的 story point（story point 也可能在之前的 product backlog refinement meeting 就已經先估好了，但此時還是可以重估）。此階段通常需要 2-4 小時。

5)進行方式（下半場）：
估算好 story point 之後，接著寫出每一個 story 的施工項目（task）。例如鄉民們要開發一個網路銀行的系統，有一個 story 是 As a user, I can view today's transaction records，那麼要完成這個 story 可能的 tasks 就有設計 UI、實做 UI 程式、寫 DAO（data access object，假設資料庫 schema 已經設計好了）、寫自動化功能測試等等。所有的 tasks 都寫好之後要開始估算完成每一個 task 所需的時間（以小時為單位）。此階段通常需要 2-4 小時。

5)結尾：
Stories 與 tasks 都估算好之後，可以準備結束會議了。並請 Developers 在離開會議適之前先認領準備要施工的 tasks 並且在該 task 上面簽名。

Cite by :
Scrum 是什麼（5）：初探 Sprint Planning Meeting

回到 軟體工程の學校專題怎麼做-Leason(3)團隊合作