深藏若虛

Scrum 相關事件的時間長度建議

這些資訊是參考自《Essential Scrum》的建議去筆記的,並非來自於個人的經驗,畢竟我引導的團隊和會議數還太少了。

建議的時間長度

一個時間長度為兩週一個月的衝刺,用於衝刺規劃的時間應該不超過 4 至 8 小時。

在為期兩週的衝刺裡,衝刺執行可能佔了總共十天裡大約八天的時間。

在進行衝刺時的每一天,而且最好在同樣的時間,開發團隊應該召開一個不超過十五分鐘的每日 Scrum 會議⋯⋯

每日 Scrum 會議是為時 15 分鐘、有時間限制的活動,每 24 小時一次就進行一次。

團隊應該保留不超過 10% 的時間,用來協助產品負責人修整產品待辦清單(撰寫、精煉、估算待辦清單,以及排列優先順序),確保這些項目已準備就緒。

一般來說,衝刺成果審查以不超過 4 小時為原則。已經有許多團隊發像一項不錯的規則:「衝刺若為一週,換算成會議時間就是一小時」。

根據我的經驗,新的 Scrum 團隊保留的時間常常太少,在不到 60 分鐘的時間裡,很難進行一次有意義的衝刺過程回顧。有一條規則:針對為期兩週的衝刺,我通常會保留大約 1.5 個小時來進行衝刺過程回顧,衝刺時間若較長,則按比例增加回顧時間。

——《Essential Scrum 中文版》,p.347、p.353、p.361、p.369、 p.381、p.394

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. 

The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. 

This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter.

Refinement usually consumes no more than 10% of the capacity of the Development Team. 

This is at most a three-hour meeting (Retrospective) for one-month Sprints. For shorter Sprints, the event is usually shorter.

——《Scrum Guide》

綜合上面的引文,我們大概可以得出下面的概念:

  • Sprint 的長度,以不超過一個月為原則。
  • Sprint Planning 的時間按比例來算的話,大概是 2 個小時/週為單位。
  • Spring Execution 大約會佔據整個衝刺日程的 80%。
  • Daily Scrum 不超過 15 分鐘。
  • Sprint Review 的時間按比例來算的話,大概是 1 個小時/週為單位。
  • Product Backlog refinement 不能超過整個衝刺時間長度的 10%。
  • Spring Retrospective 比較特別,他至少會需要 1 小時,然後再以 1.5 個小時 / 2 週為單位。

各種長度衝刺的活動時長

1 week / sprint

  • 通常會有 5 個工作天,假設 1 天工作 6 小時。
  • Sprint Planning 以不超過 2 小時為原則。
  • Spring Execution 在扣除 Scrum Events 後,大致只剩 4 個工作天。
  • Sprint Review 大致為 1 小時。
  • Product Backlog refinement 的總時長不超過 3 小時,若是平均分攤到每天,則每天不超過 35 分鐘。
  • Spring Retrospective 大致為 1 小時。
  • 通常建議將 Planning 放在週一,Review 和 Retro. 放在週五;但也有團隊希望能集中在同一天,所以會在某一天耗時 4 小時將這三個活動辦完。
  • 實際工作時間約為 23 小時。

2 weeks / sprint

  • 通常會有 10 個工作天,假設 1 天工作 6 小時。
  • Sprint Planning 以不超過 4 小時為原則。
  • Spring Execution 在扣除 Scrum Events 後,大致只剩 8 個工作天。
  • Sprint Review 以不超過 2 小時為原則。
  • Product Backlog refinement 的總時長不超過 6 小時,若是平均分攤到每天,則每天不超過 35 分鐘。
  • Spring Retrospective 大致為 1.5 小時。
  • 大致聽過以下幾種方式舉行三大活動:
    • 將 Planning 放在週一,Review 和 Retro. 放在下週五,這是最常聽到的;
    • 將 Planning、Review、Retro. 按照順序舉行,但安排日程不定;
    • 有些特殊情況團隊希望能集中在同一天,所以會在某一天耗時 7.5 小時將這三個活動辦完。但這部分會很消耗團隊體力,通常到最後一個活動時就比較沒精神了,隔天可能也會比較沒有產能。
  • 實際工作時間約為 46.5 小時。

3 weeks / sprint

  • 通常會有 15 個工作天,假設 1 天工作 6 小時。
  • Sprint Planning 以不超過 6 小時為原則。
  • Spring Execution 在扣除 Scrum Events 後,大致只剩 12 個工作天。
  • Sprint Review 以不超過 3 小時為原則。
  • Product Backlog refinement 的總時長不超過 9 小時,若是平均分攤到每天,則每天不超過 35 分鐘。
  • Spring Retrospective 大致為 2 小時 15 分鐘。

4 weeks / sprint

  • 通常會有 20 個工作天,假設 1 天工作 8 小時。
  • Sprint Planning 以不超過 8 小時為原則。
  • Spring Execution 在扣除 Scrum Events 後,大致只剩 16 個工作天。
  • Sprint Review 以不超過 4 小時為原則。
  • Product Backlog refinement 的總時長不超過 12 小時,若是平均分攤到每天,則每天不超過 35 分鐘。
  • Spring Retrospective 大致為 3 小時。

結語

這上面都是建議的數值而已,實際還是要以專案大小、團隊成立時間長短、團隊成員數量、是否有遠距離/遠端的團隊成員等等去調整。重點還是在盡量定期、定時去舉行,培養出團隊對於衝刺和相關事件的節奏感,這樣習慣之後,才能保持最適合團隊進行「衝刺」的壓力與步調穩定前進。


1 這邊在實際職場環境都會假設 1 天的工作時數是 8 小時,但私心其實會比較偏好 6 小時。就個人與身邊程式設計師朋友的經驗,一天能專注的時間大致最多就是 6 小時,甚至 6 小時就已經很多了,超過這個時數在工作下去效率就會掉得很快。另外將時間縮緊,也能幫助團隊成員保持「衝刺」的緊張感,而不會浪費時間。畢竟當時間越充裕,越有可能引發 Parkinson’s Law。所以寧願讓大家好好專注這 6 小時,剩下的時間看是否拿去放鬆、做 Side Project、與工作無關的活動、甚至早點下班好好陪家人,也不要讓大家被綁在位置上浪費人生。


Information Technology