歪歪凍的細細私語

[PMBOK Guide 4th,131]

根據PMBOK的定義，時間管理共有以下6個流程

1. 定義活動 (Define Activities)
2. 排序活動 (Sequence Activities)
3. 估算活動資源 (Estimate Activity Resources)
4. 估算活動期程 (Estimate Activity Durations)
5. 發展時程 (Develop Schedule)
6. 控制時程 (Control Schedule)

定義活動

和傳統專案管理方法不同，Scrum專案會在Sprint Planning Meeting第二部份進行時，由團隊自行將Story拆解成細部執行的Task。因為團隊才是真正開發實作Story的人，所以由他們來進行拆解，才會得到較為符合現實情況的結果。

排序活動

因為每個Sprint的週期很短，能做的Task數量也有限，因此不同於傳統方法需要考慮許多活動的優先順序，這些有限且少量的Task通常都可以透過人腦自動地做排序。由於團隊能夠掌握每一個Task的實作細節，所以當全部的Task一被列出來時，若有相依性及順序性的項目，團隊自然地會互相協調與合作，依序處理這些Task。

估算活動資源

在敏捷專案當中，團隊成員的組成通常都是固定且專職的，再者對於工作的分配，是由團隊自行去認領Task，而非是被指派。因此對於Scrum專案而言，是不需要特別做估算活動資源這件事情的。

估算活動期程

在Sprint Planning Meeting第二部份進行時，當團隊將Story拆解成Task後，便會再利用Planning Poker來估算每個Task的工時。和估算Story Point的玩法相同，只不過工時是改用小時來做為單位。一個Task最好是小於8小時，好讓工作能在一天之內完成。如果這Task的估計工時大於40的時候，則很有可能這一個Task會在為期兩週的Sprint週期內無法做完，此時便需要再將Task拆解到更小，以符合Timebox的限制。

發展時程

估計完所有Task的工時後，便能將其加總，來得到這些Task總共需要多少時間來完成。若超出了一個Sprint期間團隊所擁有的總工時限制，自然僅能請PO將最不重要的Story移往下一個Sprint。假若是還有空閒的時間，PO亦能從Product Backlogs中取出最優先的Story加入到這個Sprint。要嚴守Timebox的限制，生孩子就是要10個月，多加10個孕婦也沒辦法1個月就生出來。

控制時程

時程的掌控則是透過團隊每天在Daily Standup Meeting時，更新Task borad及Burndown chart的狀態來得知。從Burndown chart上可看出剩餘工時的走勢是在減少還是增加，從Task borad上可看出未完成的Task及Story有哪些。團隊可藉由這些資訊及早得知是否有障礙發生並將之處理，以求順利達成本次Sprint的承諾。