Foxbrush

From: http://teddy-chen-tw.blogspot.tw/2012/01/scrum-5-sprint-planning-meeting.html

=====================================================

今天介紹一下 Sprint Planning Meeting，請參考下圖：

Sprint Planning Meeting

• 開始時間：每個 sprint 開始的第一天舉辦此會議。Teddy 的經驗是每雙週的週一（Teddy 採用長度為兩週的 sprint）早上 10:00 開始 sprint planning meeting。
• 參加人員：Product Owner、Scrum Master、Developers。
• 會議目的：會議目的是產生一份 sprint backlog（包含每個 story 細分之後的施工項目）讓 Developers 可以開工。
• 進行方式（1）：由 Product Owner 逐一詳細介紹這個 sprint 要施工的每一個 stories，並且與 Developers 互動，如果 Developers 對於 stories 內容不了解一定要發問。 介紹完之後 Developers 開始估計每一個 story 的 story point（story point 也可能在之前的 product backlog refinement meeting 就已經先估好了，但此時還是可以重估）。此階段通常需要 2-4 小時。
• 進行方式（2）：估算好 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 小時。
• 結尾前：Stories 與 tasks 都估算好之後，可以準備結束會議了。在散會之前 Teddy 會請 Developers 先認領一下要施工的 tasks。以 Teddy 的經驗，如果是 10:00 開始 sprint planning meeting，通常在 15:30~16:30 左右會議就可以結束了（有時候甚至會提早在 15:00 就結束了），所以當天還有幾個小時可以施工。因此會請 Developers 在離開會議適之前先認領準備要施工的 tasks 並且在該 task 上面簽名。
• 結尾後：Teddy 有使用 ezScrum 這套工具來管理 stories 與 tasks，所以會議結束之後 Teddy（Scrum Master）會把 stories 與 tasks 的資料打到 ezScrum 系統中，大概需要 20-30 分鐘。此外，Teddy 也有使用實體的 task baord，就是在一塊白板上面把 Stories 與 tasks 都貼上去。所以，在把資料打入 ezScrum  之後，Teddy 就會把這些實體的 story cards 與 tasks（寫在 3M 小紙條上）貼到白板上面。附帶說明一下，每一張 story card 與 task 一定要用「小磁鐵」固定在白板上，否則過幾天之後很容易跟秋天的楓葉一樣，掉滿地...Orz。

有的人會把 sprint planning meeting 分成「上半場與下半場」，也就是 Teddy 上面所說得「進行方式（1）與進行方式（2）」，然就建議 Product Owner 只需要「上半場」在場就可以了，之後估算 tasks 的活動如果  Product Owner 需要趕場的話就可以離開。不過以 Teddy 的經驗，很多對於需求的問題都是在下半場估算 tasks 的時間才會冒出來，所以 Teddy 覺的 Product Owner 最好全程都在會比較好一點。


另外，如果團隊剛開始導入 Scrum，極有可能會覺的很難估算 story points 與 tasks，會有好幾個 sprints 的陣痛期每次 Sprint Planning Meeting 都搞得很痛苦，甚至會覺的時間不夠用無法在一天內完成。（迷之音：此為正常現象，請安心服用）。Teddy 剛開始採用 Scrum 的時候也有類似的困擾，但是時間一久這個問題就消失了。


Sprint Planning Meeting 在 Scrum 中是一個很重要的活動，因為後續的開發活動都仰賴這個會議所產生的 sprint backlog。在傳統的 waterfall  開發方式中，當 Developers 拿到所謂的「分析設計文件」的時候，他們的腦袋中可能對於接下來要如何施工還是一片空白。但在 Scrum 中由於有了Sprint Planning Meeting 這個活動，每個 Developers 去認領 tasks 時其實對於要做什麼事情自己心中多多少少已經有了底（當然在實際施工的時候還是有可能有問題產生），所以相較起來後續的施工問題會少很多。所以 Teddy 覺的 Sprint Planning Meeting 真的是一個很偉大的發明...XD。