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

我们究竟化了多少间?

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

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

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

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

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

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

2%的回顧

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

2.5%的評論和反饋

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

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

2.5%協調每日 Standup

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

5%規劃和設計

最大的 Scrum 活動是規劃下一個 sprint，並就如何處理工作進行高級設計。傳統開發團隊在規劃和設計方面花費了更多精力，而 Scrum 團隊完全減少了這一點。然而，這一事件是最具爭議性的事件，可能團隊認為這 5% 時间仍然很長。我個人不認為要求任何團隊有 5%的時間來計劃和設計即將開展的工作是一個很大的問題。當然，專業人士應該能夠認識到計劃的重要性。

88%工作時间

明显我们还有大比率時間去工作。這是一些更多的事實如下:

會議每天 1 小時（平均）

如果你把它看作平均每天只有一個小時的會議，是多是少见仁见智吧。

時間盒

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

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

示例計算