今天我們來探討一下如何決定一個 Sprint 要拿多少 Story

通常會有下面兩種方式進行

• Velocity based
• Commitment based

Velocity based

根據之前每一個 Sprint 所完成的 story point 來當參考依據,來決定這一個 Sprint 要拿多少 Story.
在 Velocity based 裡,雖然每次參考的就是之前所完成的 Story point, 但是他總是有高有低,可能有下面幾種情況

• 高的時候可能是全員到齊,低的時候可能是團隊中的高手請假,以致於產能下降,
• 或者是高的時候可能那個星期的 Stroy 都很順利,沒有欠缺什麼東西,或是沒有什麼相依性, 低的時候可能欠東欠西的.
• 高的時候可能團隊那個星期外務比較少,低的時候可能團隊那星期外務很多

總之高高低低有很多不同的原因,理論上我們都希望他能維持一定水準甚至是會越來越好,因為可能大家的技能提升,默契變好,做久了越做越順手等,但實際上總是有很多不同的原因導致高低起伏,而我們也不會每個 Sprint 都去記錄這些細節的部分.所以我個人認為 Velocity 真的只是純參考.
另外團隊也有可能覺得我們之前就拿這樣,所以這次也拿這樣,當做到 Story 快結束時,就會自動的調整做事的速度,以符合自己的預期(人會有實現自我預言的本能)

Commitment based

一次拿一個 Story, 拿完後 Team 決定是否還有能力繼續拿下一個 Story, 如果有就繼續拿,如果覺得吃不下做不完了就停止,這個 Sprint 就拿這些 Story.
在Commitment based裡,雖然是讓團隊自己決定是否還能吃的下,但是吃的下的依據又是什麼?大部分的團隊都是憑感覺,雖然這種感覺很準(實現自我預言的本能)

Velocity vs Commitment

這裡我們來想像一下,如果有兩各團隊,一個採用 Velocity based 一個採用 Commitment based, 一兩年後可能會發生的情況會是什麼.

Velocity based,因為每次的 Velocity 總是高高低低,久而久之團隊會覺得這是正常的,所以會越來越不重視Velocity,認為他不準,每次決定要拿多少 Story point時就會跟上次一樣,如果做不完就會說我們沒有估準(雖然說估算的目的不在準確),做的完就會說你看這次準了吧!

Commitment based,因為每次都是我(團隊)說了算,也沒有依據,最後可能演變成看心情,這星期跟女朋友吵架,所以少拿一點,年底了要發獎金了,要認真一點,所以就多拿一些.

當然目前想的都是一些成熟度比較低的團隊所會發生的例子,雖然兩種方式都有他的缺點,但在一個剛開始的 SCRUM團隊,還是要挑一個來當基本,然後在慢慢的透過不斷的持續改進找到比較適合自己的方法.

在這裡我個人是偏向是先根據上一個 Sprint 做多少,這個 Sprint 就拿差不多的 Story point , 然後

• 相信團隊如果發現做不完,會來跟 PO 回報後面的 Story 可能做不完,讓 PO 瞭解目前的進度及風險以及對策.
• 相信團隊如果提前做完了,會來跟 PO 要下一個 Story, 讓 PO 瞭解團隊會主動來做事情.
  當然這是在一個成熟度比較高的團隊應該看到的情況.