帶著大家看白板貼的從Wiki印下的Scum Plan圖。Molly繼續談如何做Sprint計畫，Sprint 在很多地方都被翻譯為『短衝』，取自美式足球，緊湊感是還蠻傳神的： “我們假設Product Owner 已經有排序好的代辦清單，就由開發成員規劃第一個Sprint計畫。會議有Product Owner 一起協商適當的 Sprint 目標，必要時可讓Scrum Master 協助會議依照Scrum精神進行。”

Gavin對Scrum精神很感興趣，因為他擔心他會是那個破壞規則的人。Molly知道這問題的背景是什麼，回答：

“如何達成Sprint 目標，是由開發成員來承諾的。注意不包含 Product Owner 以及Scrum Master這兩位，除非剛好他們有兼任開發成員。不過剛剛我說了不建議如此。我個人很強調這一點，我相信後續如果我們採用 Scrum，我們第一次做 Sprint Plan 就可以一起感受這個。”

“我看了一些Scrum 文件，難怪這個會議幾乎是 Scrum 要花費最長時間的。知道客戶需求願望的Owner，通常看到開發團隊自己訂出來的計畫都會嚇一跳吧? 慣性使然Owner 通常會壓縮開發時程，會議可能很尷尬。” Gavin 管理專案久了，一聽就知道這會議不好開。

佳麗看到與 UP 的其中一個差異：“的確，這樣子會有點拉鋸，UP 因為採所謂的 Model Driven Development，我們公司直接就是 Use-Case Driven Development，如果在分析時有做好 Use-Case 的大小控制，那麼做計畫就可以開發團隊的能力去逐步推估出每個 Iteration 要消化多少 Use-Case" 佳麗也允諾如果有機會用 Use Case 做 OOAD 她會帶著大家去嘗試控制 Use Case 的大小。

Molly 很高興聽到這個："的確Scrum沒像 UP 專為軟體開發優化到極致，所以做計畫更多的是開發團隊與 Product Owner 之間的拉鋸，較難有一個章法。到這邊我講快一點，有實際採Scrum專案時再說明細節。開始 Sprint後，開發成員，注意可以不包含Owner/Master，每天花個十五分鐘左右，站立開個所謂的 Daily Scrum。考一下 Moore, 你知道 Daily Scrum？”

“Daily Scrum 每天成員花十五分鐘內，大家一起站著報告一下四個要點: 昨天我針對Iteration，如果Scrum 就是 Sprint Plan 做了什麼事；今天我打算做什麼；我是否遇到困難或是看到什麼風險；是否有心得或是特殊事項要跟成員分享” Moore 在公司應該至少有千次 Daily Scrum了，順口背出來。

“怎麼有四項，看來多了最後一項心得分享” Molly有點訝異。

“第四項是大老闆在我們公司獨創的 Daily UP時添加進第四項的，期盼成員要能時時分享。好像一般 Daily Scrum 不會有這樣的活動” Pete 搶答。

"這家公司難怪在艱困產業裡還能賺大錢，這真是競爭利器啊！我猜大家總覺壓力很大吧？我剛來還沒感受。" 說完大家哈哈苦笑。這還用說，對岸說這行業是碼農，真是一分耕耘一分收穫的行業，還得看天（客戶）吃飯。

“有一個特殊的情況，一個正在進行的 Sprint，Product Owner 是可以隨時取消這個正在執行的 Sprint。例如：客戶提出需求變更，而且Owner研判是合理的，該變更與正在開發的內容是衝突的，Product Owner 就必須緊急停止這個 Sprint，然後安排下一個Sprint 計畫會議”

Gavin 體會到此：”基本上這個機制可以降低需求變更衍生的開發成本，但是我相信不會常發生，畢竟Sprint大概二到四週的這麼短的時程，要發生大變更機率不高。聽到這裡我幾乎想採 Scrum 在 AI探索專案。Molly 還是請你多少講一下那個非軟體開發專案，幫助我更有信心去說服 RJ或者大老闆採用 Scrum。”