Scrum 是什麼（6）：Sprint Planning Meeting 眉角

January 11 09:51~11:22

前情題要：

• 〈Scrum 是什麼（1）：雙重回饋機制〉
• 〈Scrum 是什麼（2）：Scrum 的內涵〉
• 〈Scrum 是什麼（3）：三種補充文件〉
• 〈Scrum 是什麼（4）：Product Backlog〉
• 〈Scrum 是什麼（5）：初探 Sprint Planning Meeting〉

對於一個剛開始導入 Scrum 的團隊，sprint planning meeting 最頭大的問題應該是「如何決定每一個 story 的 story point 以及 task 所需的時間」。關於 story points 與 tasks 的估算方法請參考「如何估算 story point？」與「Story point 為何沒有單位：相對論篇」。今天 Teddy 要講的是，假設團隊有 5 個人，現在要估算某個 story 的 story point，結果 5 個人出的牌（假設團隊用 Scrum Planning Poker 的方式用來估算點數）點數分別是：

• A：13
• B：2
• C：20
• D：?（問號）
• E：5

那麼這個 story 的 story point 要算多少？會出現這種估算結果，通常有幾個原因：

• 團隊成員對於 Product Owner 所解釋的需求內容產生了「一個 story 各自表述」的現象，所以才會出現 B 認為只需要 2 點而 C 認為需要 20 點這麼大的差距。遇到這樣的情況可以請每個人說明一下他們估算點數的依據，如果時間不夠也可以請差距最大的兩方（B 和 C）說明就好。經過一番說明與討論之後（Product Owner 和團隊成員要互相討論）Scrum Master 請大家再重新估算一次，通常這個時候估算的結果差異會比較小。重複這個過程一直到得到一個大家都認可的點數為止。有人會問如果一直都沒有得到一個大家認可的點數該怎麼辦？重估的過程 Teddy 最多大概只會進行兩次（包含第一次的估算，最多一共估算三次），如果此時還是無法得到共識，Teddy 會自行決定一個「合理」的點數，通常團隊成員也 不敢 不會有太大的意見（因為一直重估太多次大家也是會累的...XD）。
• 完全不了解這個 story （或是 task）是要做什麼的。例如，D 出了？（問號）這張牌，表示他對於這個 story （或是 task）完全不了解。此時就要請 Product Owner 針對 D 不了解的地方再次說明。如果估算的是 task 的話，則可以請對於實做該 task 有經驗的團隊成員說明一下。之後，回到上一點所說得，再次重估。
• 團隊成員不合作。剛開始實施 Scrum 時可能會有那種打死不合作的「刀民」，就是不想了解也不想認真參與估算，總是會在旁邊講一些有的沒的風涼話。如果是這樣的情況，Scrum Master 可以選擇先把該刀民當成隱形人（小時候玩捉迷藏不是有一種人叫做「烏鴉」的嗎？），告訴他先看看別人如何估算，等他了解之後再加入估算的活動（迷之音：如果團隊成員全部都是刀民...Orz）。

有一件很重要的事情 Scrum 團隊要銘記於心，Scrum 所設計的各種活動其目的是要強調「溝通」，尤其是「面對面的溝通」。如果只是想從 Product Owner 所寫出來 不清不楚 ... 嗯嗯，那一句短短的 story（As a user, I can...）就可以知道程式要怎麼寫，那是不可能的。所以在 sprint planning meeting 的過程中，團隊成員對於 story 與 task 有任何不了解的地方，一定要立即發問，主動參與。Teddy 最怕那種在 sprint planning meeting 中都不開口的團隊成員，看起來好像都沒問題，但是等真正開工之後，這種人通常問題最多。

***

開 sprint planning meeting 是一件很累人的活動，但對於日後 sprint 的進行是否順利有著決定性的影響。對於剛開始實施 Scrum 的團隊，sprint planning meeting 很可能會佔據一整天（6-7 小時）的時間，而且開完會之後對於接下來要做的事情可能還是會有一種「毛毛的感覺」。這種現象可能會持續一段時間，例如半年以上。等團隊成員默契慢慢培養起來之後，sprint planning meeting 就會進行的比較順利。至少大部分的時間都可以花在「討論真正的問題上面」，而不是花在處理「刁民」與「派大星（拒絕動腦筋的人）」身上。

 

最後一個重點，如果快到下班時間而 sprint planning meeting 還沒開完怎麼辦？要明天繼續嗎？No, no, no, 千萬不要。請記得 agile 的核心精神就是 time boxing（編列固定預算的概念），任何活動都是有一定的時間，如果真的發生快到下班時間而 sprint planning meeting 還沒開完，那就「草草結束這次的 sprint planning meeting 吧」。蛤，蝦米，草草結束，這是什麼態度？

 

沒錯，就是草草結束，因為如果把 sprint planning meeting 一直延長下去很可能會出現 big up-front design 的症狀。對於新的 Scrum 團隊，很可能團隊成員大多還是抱持著傳統那種「先好好地分析設計一番，然後再開工」的習慣。所以，如果真的無法在預定的時間開完會議，就草草結束，反正有問題 sprint 進行的過程中隨時都可以問 Product Owner。如此一來才可以：

 

• 強迫 循循善誘團隊成員慢慢接受 time boxing 的工作模式。
• 這次 sprint planning meeting 花太多時間討論一些可能不是很重要的細節，導致於最後落得草草結束的下場。團隊學得此次經驗之後，下一次的 sprint planning meeting 會儘量避免同樣的問題發生。

***

下一集：〈Scrum 是什麼（7）：Daily Scrum〉

***

 

友藏內心獨白：難道每天寫一篇對於鄉民來說會看的太累嗎？