Daily Scrum
Tägliches 15-Minuten-Event zur Anpassung des Plans.
Das Daily Scrum ist ein 15-minütiges Event der Developers zur Inspektion des Fortschritts in Richtung Sprint Goal und zur Anpassung des Sprint Backlogs. Es ist KEIN Statusreport an den Scrum Master und keine reine Pflichtübung.
Passende Übungsfragen
☝️ SingleEin Scrum-Team stellt beim Daily Scrum fest, dass es das Sprint-Ziel voraussichtlich nicht erreicht. Welche Säule der Empirie wird als Nächstes wirksam?
✅Adaption – der Plan wird angepasst
❌Inspektion – nur beobachten
❌Keine, das Daily dient nur dem Status
❌Transparenz – nichts ändern
Nach der Inspektion (Erkennen der Abweichung im Daily) folgt die Adaption: Die Developers passen ihren Plan an, um das Sprint-Ziel bestmöglich zu erreichen.
❌30 Minuten, geleitet vom Scrum Master
❌So lange wie nötig, für alle Stakeholder
✅15 Minuten, für die Developers
❌1 Stunde, für das ganze Unternehmen
Das Daily Scrum ist ein 15-minütiges Event für die Developers, um den Fortschritt zum Sprint-Ziel zu inspizieren und den Plan anzupassen. Es ist kein Status-Report an das Management.
☝️ SingleWelches Scrum-Element dient primär der Inspektion des Fortschritts in Richtung Sprint-Ziel?
❌Das Product Backlog Refinement
✅Das Daily Scrum
❌Das Sprint Planning
❌Die Sprint Retrospective
Im Daily Scrum inspizieren die Developers den Fortschritt zum Sprint-Ziel und passen den Plan für den nächsten Arbeitstag an.
✍️ OffenEin Scrum Team ist auf 14 Personen angewachsen. Die Daily Scrums dauern 30 Minuten, Entscheidungen ziehen sich hin. Beschreiben Sie das Problem und mögliche Vorgehensweisen.
Musterantwort: Das Team liegt deutlich über der Orientierung von typischerweise 10 oder weniger Personen. Große Teams erzeugen überproportional viele Kommunikationswege, was Abstimmungsaufwand, Entscheidungsdauer und Event-Länge erhöht und die Kohäsion senkt. Mögliches Vorgehen: das Team selbst die Aufteilung erarbeiten lassen (Selbstverwaltung) – etwa entlang von Produktbereichen, Wertströmen oder Nutzergruppen, nicht entlang von Fachdisziplinen, damit jedes entstehende Team cross-funktional bleibt und eigenständig ein Increment liefern kann. Wichtig: bei einem gemeinsamen Produkt bleibt es bei EINEM Product Backlog und EINEM Product Owner; jedes Team braucht eine gemeinsame Definition of Done und ein integriertes Increment. Alternativ prüfen, ob das Team nur temporär gewachsen ist. Ein Skalierungsrahmenwerk (z.B. Nexus) ist erst sinnvoll, wenn mehrere Teams dauerhaft am selben Produkt arbeiten.
Bewertet werden: Bezug zur Größenorientierung (10 oder weniger) + Kommunikationsaufwand als Ursache + Aufteilung durch das Team selbst + Schnitt nach Wert statt nach Fachdisziplin + gemeinsames Product Backlog/PO/DoD bei einem Produkt.
✅Weil alle anderen Scrum-Events innerhalb des Sprints stattfinden
❌Weil er alle Product-Backlog-Einträge enthält
❌Weil er das fertige Produkt enthält
❌Weil er die Arbeit mehrerer Teams bündelt
Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospective finden alle innerhalb des Sprints statt.