在上一篇文章《敏捷方法的成功密技（十）：Scrum 的衝刺目標誰決定？》當中，我們談到了衝刺（Sprint）目標，雖然名義上應該由 Product Owner（產品負責人）來制定，但為免團隊根本就不 buy-in，或是團隊實在是無力可達成，故，實務上 PO 仍應與 Scrum Master 和開發團隊「一起」討論，來制定各個衝刺的目標，這樣才像一個符合 Scrum 精神的「團隊」！
假設當初在衝刺規劃會議時，設定衝刺的週期為兩週（10 個工作天）一個輪迴，開發團隊總共有五個人，那麼開發團隊就總共有 5 x 10 = 50 天（50個 man-day）可用。又假設，當初在衝刺規劃會議時，團隊對於「用戶故事點數（User Story point）」的認知，定義為「一點等於一個 man-day」，那麼，衝刺的容量就是 50 點。
當我們依用戶故事的優先級先後，把它們一一塞進第一個、第二個…衝刺之後，絕對會發生一件事，那就是，每個衝刺都會有一些剩餘的空間，無法有適合的故事去填補、塞滿！那該怎麼辦呢？
解決方法其實可以有兩種！
其一是，我們大可以直接在產品待辦事項清單（Product backlog）內，選一些大小合適，但優先級卻不是這麼高的用戶故事，來塞滿各個衝刺的剩餘空間。雖然這樣做，也不會對產品和團隊造成多大的傷害，但是，這樣做並不夠符合 Scrum 的精神，也就是「高優先級用戶故事，必定是提供用戶較高的價值，所以應該優先做」。
比較好的方式，應該是「將較重要（高優先級），又比較肥大（用戶故事的點數較多）的用戶故事拆解為數個小巧的用戶故事」！這樣做的結果就是，各個衝刺的剩餘空間都會變得更少，更容易可以被塞滿。
例如，假設衝刺一的容量還有 5 點的剩餘空間，而衝刺二的第 1 個（高優先級）用戶故事卻是 7 點大小，所以衝刺二的第 1 個用戶故事是無法往前塞進衝刺一的。可是如果衝刺二的第 1 個用戶故事，其實還有可能可以被 PO 和開發團隊一起拆解為兩個小故事，優先級先後和其大小分別是「5 點」和「2 點」，那麼，「5 點」的小故事就能被往前搬到衝刺一去執行了，「2 點」的小故事也能繼續放在衝刺二了。
延伸上述的例子，假設這個「2 點」的小故事，其實已經比衝刺二內其他的用戶故事優先級還要低了，那麼，這個「2 點」的小故事就可以往後搬了，繼續跟衝刺三的用戶故事比，一路這樣比下去，就會發現，搞不好這「2 點」的小故事根本就已經排到第十幾衝刺去了！
回過頭來，經過這樣「將優先級高的大故事，拆解為數個小故事」的技巧，各個衝刺最後仍然會有一些零星的剩餘空間，那又該怎麼辦？
其實，只要即將要執行的這前幾個衝刺有做到這些動作，整個產品的用戶故事優先級也就守得八九不離十了，也就是說，開發團隊的精力也幾乎都用在對的時機和對的事物上了。這時，不妨就拋開優先級的束縛，從產品待辦事項清單內，往下（低優先級的方向）找一些大小合適的用戶故事，去塞滿這前幾個衝刺的剩餘空間吧，因為，這其實已經不影響大局了！
說到這了，有經驗的您也許發現了一個潛在的問題，那就是，怎麼可能那麼理想，一個工作天可以完全被用來做產品開發相關的工作？那公司或部門的例行性會議，不用花開發團隊的時間嗎？團隊成員都不會生病請假嗎？特休假、國定節慶假日不用考量嗎？不用考慮滑手機、看 FB 的放鬆調節空檔嗎？
是的，您的考量一點也沒錯！欲知詳情，請待我下回來分曉！
