Overview
- What you’ll learn: Common dysfunctions in each Scrum event, how to diagnose them, root causes, and practical fixes.
- Prerequisites: Lessons 17–23 (all Scrum events + facilitation).
- Estimated reading time: 14 minutes
Introduction
Every Scrum Team eventually encounters events that feel broken. Sprint Planning drags on for hours. The Daily Scrum becomes a status report marathon. Sprint Reviews are demos that nobody attends. Retrospectives produce the same complaints every Sprint. Recognizing the symptoms and understanding the root causes is the first step to fixing them.
Sprint Planning Dysfunctions
| Symptom |
Root Cause |
Fix |
| Takes 4+ hours for a 2-week Sprint |
PBIs not refined before Planning |
Invest in backlog refinement during the Sprint |
| No Sprint Goal emerges |
PO lacks product vision or brings disconnected items |
PO prepares a clear proposal before Planning |
| Team over-commits |
Pressure from management or unrealistic optimism |
Use historical velocity/throughput data to forecast |
| Only the “How” is discussed |
PO absent or disengaged |
PO must attend and lead the “Why” and “What” topics |
Daily Scrum Dysfunctions
| Symptom |
Root Cause |
Fix |
| Runs over 15 minutes |
Problem-solving during the event |
Park detailed discussions for after the Daily |
| Feels like reporting to the SM |
SM leads the meeting |
SM steps back; Developers own and lead the event |
| People are disengaged |
No connection to the Sprint Goal |
Frame the conversation around the Sprint Goal, not tasks |
| Same impediments every day |
Nobody is removing impediments |
SM actively works on impediment removal between Dailies |
Sprint Review Dysfunctions
| Symptom |
Root Cause |
Fix |
| No stakeholders attend |
Reviews are boring presentations |
Make Reviews interactive; invite stakeholders to use the product |
| Only positive feedback |
Stakeholders don’t feel safe criticizing |
Explicitly ask: “What would make this better?” |
| Nothing changes after the Review |
Feedback is not captured or acted on |
Update the Product Backlog during/immediately after the Review |
Sprint Retrospective Dysfunctions
| Symptom |
Root Cause |
Fix |
| Nobody speaks up |
Lack of psychological safety |
Start with anonymous written input; build trust over time |
| Same complaints every Sprint |
Identified improvements never implemented |
Add improvement items to the Sprint Backlog; follow up next Retro |
| Skipped “because we’re too busy” |
Team doesn’t see the value |
Start with short, focused Retros; demonstrate impact of improvements |
| Blame-fest |
Unsafe environment; external blame culture |
Use the Prime Directive: assume everyone did their best |
Key Takeaways
- Every Scrum event can become dysfunctional — recognize symptoms early.
- Root causes are usually: lack of preparation, lack of safety, SM over-involvement, or missing feedback loops.
- Fixes usually involve: better preparation, stepping back, building trust, and making improvements visible.
- The Retrospective is the meta-event — use it to fix the other events.
What’s Next
Congratulations — you have completed Module 3: Scrum Events! In Module 4, you will explore Scrum Artifacts and their commitments — the Product Backlog, Sprint Backlog, and Increment.
繁體中文
概述
- 學習目標：每個 Scrum 事件的常見功能障礙、如何診斷、根本原因和實際修復方法。
- 先決條件：第 17–23 課。
- 預計閱讀時間：14 分鐘
簡介
每個 Scrum 團隊最終都會遇到感覺壞掉的事件。識別症狀和理解根本原因是修復的第一步。
Sprint 規劃功能障礙
| 症狀 |
根本原因 |
修復 |
| 兩週 Sprint 開 4 小時以上 |
PBI 在規劃前未精煉 |
在 Sprint 中投資待辦清單精煉 |
| 沒有 Sprint 目標出現 |
PO 缺乏產品願景 |
PO 在規劃前準備清楚的提案 |
每日 Scrum 功能障礙
| 症狀 |
根本原因 |
修復 |
| 超過 15 分鐘 |
在事件中解決問題 |
詳細討論留到每日 Scrum 之後 |
| 感覺像向 SM 報告 |
SM 主導會議 |
SM 退後；開發者主導 |
Sprint 回顧功能障礙
| 症狀 |
根本原因 |
修復 |
| 沒人發言 |
缺乏心理安全感 |
用匿名書面輸入開始 |
| 每個 Sprint 相同抱怨 |
改善從未被實施 |
將改善加入 Sprint 待辦清單 |
重點摘要
- 每個 Scrum 事件都可能變得功能障礙——及早識別症狀。
- 根本原因通常是：缺乏準備、缺乏安全感、SM 過度介入。
- 回顧是元事件——用它來修復其他事件。
下一步
恭喜——您已完成模組 3：Scrum 事件！在模組 4 中，您將探索 Scrum 工件及其承諾。
日本語
概要
- 学習内容：各スクラムイベントの一般的な機能不全、診断方法、根本原因、実践的な修正方法。
- 前提条件：レッスン17–23。
- 推定読了時間：14分
はじめに
すべてのスクラムチームは最終的に壊れたと感じるイベントに遭遇する。症状を認識し根本原因を理解することが修正の第一歩。
スプリントプランニングの機能不全
| 症状 |
根本原因 |
修正 |
| 2週間スプリントで4時間以上 |
PBIがプランニング前にリファインされていない |
スプリント中のバックログリファインメントに投資 |
| スプリントゴールが出てこない |
POにプロダクトビジョンがない |
POがプランニング前に明確な提案を準備 |
デイリースクラムの機能不全
| 症状 |
根本原因 |
修正 |
| 15分を超える |
イベント中に問題解決をしている |
詳細な議論はデイリー後に回す |
| SMへの報告のように感じる |
SMがミーティングをリード |
SMは一歩引く。開発者がリード |
レトロスペクティブの機能不全
| 症状 |
根本原因 |
修正 |
| 誰も発言しない |
心理的安全性の欠如 |
匿名の書面インプットから始める |
| 毎スプリント同じ不満 |
改善が実行されない |
改善をスプリントバックログに追加 |
重要ポイント
- すべてのスクラムイベントは機能不全になりうる——早期に症状を認識。
- 根本原因は通常：準備不足、安全性の欠如、SMの過剰関与。
- レトロスペクティブはメタイベント——他のイベントを修正するために使う。
次のステップ
おめでとうございます——モジュール3：スクラムイベントを修了しました！モジュール4では、スクラムアーティファクトとそのコミットメントを探ります。