Overview¶

Unlike certification-track courses, this guide is diagnostic and remedial: it's for teams that have adopted Scrum's mechanics but lost its value — going through the motions of ceremonies without real agility. The goal is to identify specific failure patterns and apply targeted fixes.

Who it's for: Scrum Masters, Agile Coaches, or team leads inheriting a struggling or "zombie" Scrum team.

Core Topics Breakdown¶

1. Diagnosing a Broken Scrum Team¶

Common symptom clusters and their likely root causes: - Sprints always fail to meet commitments → likely causes: unrefined backlog, unrealistic capacity planning, or hidden work (interruptions, support tickets) not accounted for. - Daily Scrum is a status report to the Scrum Master → sign of a command-and-control mindset still present; team hasn't internalized self-organization. - Retrospectives produce no change → action items lack owners/deadlines, or the team lacks psychological safety to name real issues. - Sprint Reviews are poorly attended by stakeholders → the Review isn't demonstrating real value, or stakeholders were never taught why their presence matters.

2. Repairing the Backlog¶

• Introducing a regular backlog refinement cadence if one doesn't exist.
• Applying the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable) to break down oversized stories.
• Establishing a Definition of Ready to prevent unrefined items from entering Sprint Planning.

3. Repairing Team Dynamics¶

• Re-establishing psychological safety after a history of blame-driven retrospectives.
• Addressing "loud voice wins" dynamics where one person dominates planning and estimation (introduce techniques like Planning Poker to surface hidden disagreement).
• Rebuilding trust between the team and a Product Owner who has a history of scope-creep mid-sprint.

4. Repairing Organizational Interference¶

• Protecting the Sprint from constant reprioritization by external stakeholders.
• Negotiating with management to reduce non-sprint interrupt work (support, ad hoc requests) that silently kills predictability.
• Addressing matrixed team members split across multiple teams, which fragments focus and accountability.

5. Repair Sequencing — What to Fix First¶

1. Stabilize the backlog (so planning has something real to work with).
2. Fix the Daily Scrum's purpose (peer coordination, not reporting).
3. Rebuild retrospective trust and follow-through.
4. Tackle organizational/structural issues last, since they usually require more time and political capital.

Study Tips¶

• Practice pattern-matching: given a described symptom (e.g., "sprints are always 150% overcommitted"), name the most probable root cause and the first repair step.
• Memorize the INVEST acronym and be able to apply it to a poorly written user story on the spot.
• Understand that repair is sequential — attempting to fix organizational issues before backlog health tends to fail because the team has no stable base to build trust from.

Common Pitfalls¶

• Trying to fix everything simultaneously, overwhelming a team that's already struggling.
• Blaming the team for symptoms that are actually caused by upstream backlog or organizational dysfunction.
• Declaring "Scrum doesn't work" after abandoning the repair before core practices (refinement, Definition of Done) are even in place.

Quick Reference Cheat Sheet¶

Further Practice¶

Pick a real (or imagined) struggling team. List their top 3 symptoms, map each to a root cause, and sequence your first three repair actions.