Scrum會議太多了! 你的團隊在Scrum活動中使用了多少時间?

Scrum事件 - 會議 太多了，太耗時了!!!

我们究竟化了多少间?

幾乎每一個我將 Scrum 引入新公司的團隊都曾在某些方面抱怨Scrum會議的持續時間。我得到的評論如下：

• “Scrum會議太多了”
• “什麼？兩個星期衝刺的四小時計劃會議！“
• ”我們在這裡舉行了很多會議，現在你們正在通過更多的會議來殺死我們“
• ”我不能讓我的團隊花費這麼多時間參加會議“
• ”我太忙了“

以下是Scrum中的事件以及每個事件的小時數：

新手團隊可能會看到這些數字在每個事件中都有大量的時間，但是如果您遵循檢查原則並實際深入了解時間; 你可能會對一些數字感到有些驚訝。

出於數學目的，我將假設平均上午9點到下午5點的工作，工作時間為8小時。我還將承擔週一至週五的工作，因為這在我與之合作的所有團隊中都很常見。

以下是Sprint中每個事件花費的時間細分：

2％的 回顧

團隊應該花時間檢查他們的流程和實踐，並尋求更好，更快地做事的機會。沒有這種檢查和精神，適應就完全喪失，敏捷的本質不存在。

2.5％的 評論和反饋

在衝刺結束時，團隊與利益相關者交談並尋求他們對剛剛完成的工作的反饋非常重要。這種風險管理策略通過允許團隊展示他們建立的內容以及利益相關者同意或糾正它來幫助儘早糾正錯位目標。不花時間做這些反饋只會導致錯誤的產品交付給利益相關者，而不是他們的期望。這通過定期反饋支持對增量和迭代開發的整體信念。

接下來是審查即將開展的工作，並允許產品負責人向團隊和利益相關者展示工作管道的健康狀況。它有助於透明地溝通產品，項目和即將開展的工作。

2.5％協調 每日Standup

每天，團隊只需要一個15分鐘的活動來計劃誰在接下來的24小時內做什麼，直到下一個每日Scrum。

5％ 規劃和設計

最大的Scrum活動是規劃下一個sprint，並就如何處理工作進行高級設計。傳統開發團隊在規劃和設計方面花費了更多精力，而Scrum團隊完全減少了這一點。然而，這一事件是最具爭議性的事件，球隊認為這仍然很長。

人們必須同意溫斯頓丘吉爾“未能計劃只是計劃失敗”。我個人不認為要求任何團隊有5％的時間來計劃和設計即將開展的工作是一個很大的問題。當然，專業人士應該能夠認識到計劃的重要性。

88％工作時间

這是完成工作的大量時間。我確實認為提煉是工作。

這是一些更多的事實

會議每天1小時（平均）

如果你把它看作平均每天只有一個小時的會議，那麼在宏觀方案中這實際上並不多。

這是一個時間盒

時間框是事件的最長時間，這意味著如果您可以更快地完成，同時提供相同的質量; 那麼請快點做。

如果你的會議次數多於Scrum會議，那麼你做錯了，組織的功能失調需要解決。

示例計算