Jeden Morgen dieselbe Runde. Jeder erzählt, was er gestern gemacht hat, was heute ansteht und ob es Blockaden gibt. Nach 15 Minuten gehen alle zurück an ihre Arbeit. Geändert hat sich wenig. Genau deshalb halten viele Teams das Daily Scrum für Zeitverschwendung. Oft haben sie damit sogar recht. Das Problem liegt allerdings selten im Daily Scrum selbst. Es liegt darin, was Unternehmen daraus gemacht haben. Daily Scrum ist Zeitverschwendung – oder doch nicht? Entscheidend ist, ob das Team Statusmeldungen produziert oder seine Arbeit tatsächlich neu ausrichtet. Ein gutes Daily schafft Fokus, macht Probleme früh sichtbar und verändert den Plan für den Tag. Ein schlechtes Daily ist schlicht ein täglicher Pflichttermin.
Was ist ein Daily Scrum?
Das Daily Scrum ist ein tägliches, auf 15 Minuten begrenztes Scrum Event für die Developer eines Scrum Teams.
Sein Zweck ist klar definiert:
- Fortschritt zum Sprint-Ziel überprüfen
- Sprint Backlog bei Bedarf anpassen
- Arbeit für den nächsten Arbeitstag neu planen
- Hindernisse sichtbar machen
- Zusammenarbeit koordinieren
Der aktuell gültige offizielle Scrum Guide stammt weiterhin aus November 2020. Dort steht ausdrücklich das Sprint-Ziel im Mittelpunkt des Daily Scrums. Die Developer dürfen Struktur und Technik des Meetings selbst bestimmen, solange am Ende ein umsetzbarer Plan für die bevorstehende Arbeit entsteht.
Das ist ein wichtiger Punkt.
Der Scrum Guide schreibt nicht vor, dass jedes Teammitglied nacheinander drei Fragen beantworten muss.
Genau dieses Ritual ist trotzdem in vielen Unternehmen zum Synonym für das Daily geworden.
Ist das Daily Scrum wirklich notwendig?
Die kurze Antwort lautet:
Ein funktionierendes Scrum Team braucht tägliche Abstimmung. Es braucht aber kein tägliches Statusmeeting.
Das Daily Scrum besitzt dann einen Wert, wenn sich nach den 15 Minuten etwas verändert.
Zum Beispiel:
- Zwei Developer arbeiten gemeinsam an einem kritischen Thema.
- Ein begonnenes Backlog Item erhält Vorrang vor neuer Arbeit.
- Ein Hindernis wird sofort adressiert.
- Das Team erkennt eine Gefahr für das Sprint-Ziel.
- Aufgaben werden neu verteilt.
- Der Sprint Backlog wird angepasst.
- eine unnötige Aktivität wird bewusst nicht begonnen.
Wenn dagegen jeder nur erzählt, woran er arbeitet, entsteht kaum Mehrwert.
Dann ist die Kritik „Das Daily kostet nur Zeit“ berechtigt.
Warum so viele Daily Scrums Zeitverschwendung sind
Das Daily ist eines der einfachsten Scrum Events.
Und gleichzeitig eines der am häufigsten missverstandenen.
Scrum.org nennt Statusberichte, fehlenden Fokus und mechanisch abgespulte Fragen seit Jahren als typische Anti-Patterns.
Dafür gibt es mehrere Ursachen.
1. Aus dem Daily Scrum wurde ein Statusmeeting
Das häufigste Muster sieht so aus:
Der Scrum Master oder eine Führungskraft steht vorne.
Dann berichtet Person für Person:
„Gestern habe ich …“
„Heute mache ich …“
„Keine Blocker.“
Die Kommunikation läuft dadurch nicht zwischen den Developern.
Sie läuft von den Developern zu einer zentralen Person.
Das verändert den Charakter des Meetings vollständig.
Ein Statusmeeting beantwortet:
Was macht jeder Einzelne?
Das Daily Scrum beantwortet:
Was müssen wir als Team heute tun, damit wir unser Sprint-Ziel erreichen?
Scrum.org weist ausdrücklich darauf hin, dass das Daily Scrum kein Statusmeeting für Management, Product Owner oder Scrum Master ist. Es ist eine kollaborative Planung der Developer.
2. Die drei Daily-Fragen werden wie ein Gesetz behandelt
Viele kennen diese Fragen:
- Was habe ich gestern gemacht?
- Was mache ich heute?
- Was blockiert mich?
Sie können hilfreich sein.
Sie sind aber keine aktuelle Scrum-Regel.
Der Scrum Guide 2020 hat die frühere Vorgabe dieser Fragen bewusst entfernt. Die Developer können selbst entscheiden, welche Struktur ihnen hilft.
Das war eine wichtige Änderung.
Denn die drei Fragen fördern schnell individuellen Status statt Zusammenarbeit.
Ein Entwickler erzählt dann:
„Ich habe gestern Ticket 143 bearbeitet und arbeite heute weiter daran.“
Der nächste:
„Ich bin an Ticket 167.“
Der dritte:
„Ich beginne Ticket 182.“
Alle haben gesprochen.
Aber niemand hat beantwortet:
- Welches dieser Themen ist für das Sprint-Ziel kritisch?
- Warum beginnen wir neue Arbeit, obwohl andere Arbeit noch offen ist?
- Braucht jemand Unterstützung?
- Welche Aufgabe müssen wir zuerst fertigstellen?
Ein Daily Scrum darf völlig anders aussehen.
3. Das Sprint-Ziel spielt keine Rolle
Frage nach einem beliebigen Daily:
„Was ist eigentlich euer Sprint-Ziel?“
Wenn mehrere Teammitglieder darauf keine klare Antwort haben, liegt das Problem tiefer als im Meeting.
Das Sprint-Ziel ist der gemeinsame Orientierungspunkt.
Ohne dieses Ziel bleiben nur einzelne Tickets.
Dann besitzt jeder seine eigene Priorität.
Das Daily wird zwangsläufig zu einer Sammlung individueller Arbeitsberichte.
Ein gutes Daily beginnt deshalb gedanklich immer beim Sprint-Ziel:
Sind wir noch auf Kurs?
Scrum.org beschreibt genau diesen Zusammenhang. Das Team überprüft den Fortschritt zum Sprint-Ziel und passt daraufhin den Sprint Backlog an.
4. Das Team arbeitet gar nicht wirklich als Team
Manche „Scrum Teams“ bestehen faktisch aus Einzelarbeitern.
Eine Person programmiert Backend.
Eine Person arbeitet am Frontend.
Eine Person testet.
Jeder besitzt eigene Tickets.
Alle sind ausgelastet.
Aber kaum jemand arbeitet gemeinsam an einem Ergebnis.
Dann interessieren die Statusinformationen der anderen nur begrenzt.
Ein dokumentierter Erfahrungsbericht auf Scrum.org beschreibt genau dieses Problem: Wenn Teammitglieder weitgehend an voneinander unabhängigen Aufgaben arbeiten, erscheint das Daily nachvollziehbarerweise irrelevant. Die sinnvollere Lösung besteht nicht darin, das Meeting unterhaltsamer zu gestalten. Zuerst muss überprüft werden, ob überhaupt gemeinsame Arbeit an einem Sprint-Ziel stattfindet.
Das Daily Scrum macht damit häufig ein Problem sichtbar, das bereits vorher bestand.
5. Probleme werden im Daily vollständig gelöst
Das Gegenteil eines zu oberflächlichen Daily ist das endlose Problemlösungsmeeting.
Eine Person erwähnt ein technisches Problem.
Fünf Minuten später diskutieren vier Entwickler Architekturdetails.
Der Rest wartet.
Nach 30 Minuten läuft das Meeting immer noch.
Auch das ist kein gutes Daily Scrum.
Das Event soll Probleme identifizieren und die weitere Zusammenarbeit planen.
Tiefe fachliche Diskussionen können direkt danach mit den tatsächlich benötigten Personen stattfinden.
Scrum.org empfiehlt genau diese Trennung: Themen werden im Daily sichtbar gemacht. Detaildiskussionen folgen außerhalb des 15-Minuten-Events.
6. Der Scrum Master führt das Team durch das Daily
Ein häufiges Bild:
Der Scrum Master ruft Namen auf.
„Thomas?“
Thomas berichtet.
„Sarah?“
Sarah berichtet.
Damit entsteht ungewollt eine Hierarchie.
Der Scrum Master moderiert.
Die Developer liefern Informationen.
Scrum funktioniert jedoch bewusst anders.
Die Developer sind für das Daily Scrum verantwortlich. Der Scrum Master stellt sicher, dass das Event verstanden wird und innerhalb der Timebox funktioniert. Er muss es nicht täglich leiten.
Ein gutes Zeichen für ein reifes Team:
Das Daily funktioniert auch dann, wenn der Scrum Master nicht anwesend ist.
Praxisbeispiel: Drei Fragen abgeschafft – Zusammenarbeit verbessert
Ein dokumentiertes Beispiel eines Professional Scrum Trainers zeigt, wie stark die Struktur des Daily Scrums dessen Wirkung verändern kann.
Das betreute Team empfand sein Daily als langweilig und wenig produktiv.
Statt das Event abzuschaffen, änderte es den Ablauf.
Zuerst betrachtete das Team das Sprint-Ziel.
Dann bewerteten die Mitglieder gemeinsam:
Wie wahrscheinlich ist es, dass wir dieses Ziel erreichen?
Bei geringer Zuversicht besprachen sie die Ursachen.
Danach betrachteten sie zuerst die bereits begonnenen Product Backlog Items.
Die zentrale Frage lautete nicht mehr:
„Wer arbeitet woran?“
Sondern:
„Was brauchen wir, um dieses Item fertigzustellen – und wer kann helfen?“
Dadurch erkannte das Team auch, dass zu viel Arbeit gleichzeitig begonnen wurde. Es reduzierte Work in Progress und konzentrierte sich stärker darauf, begonnene Arbeit gemeinsam abzuschließen.
Der dokumentierte Effekt: Zusammenarbeit und Qualität verbesserten sich, gleichzeitig stieg der Durchsatz.
Das Meeting wurde nicht besser, weil neue Moderationstechniken eingeführt wurden.
Es wurde besser, weil sich die Frage änderte:
Von „Was mache ich?“
zu „Was müssen wir fertig bekommen?“
Ein zweites Praxisbeispiel: Das Daily zeigte ein tieferes Problem
Ein weiterer Erfahrungsbericht beschreibt Teams, bei denen offensichtliche Daily-Probleme zunächst falsch interpretiert wurden.
Bei einem Team kamen Mitglieder regelmäßig zu spät.
Die erste Vermutung:
Der Termin liegt ungünstig.
Die eigentliche Ursache lag jedoch in Unzufriedenheit mit einer veränderten technischen Strategie.
Bei einem international verteilten Team wirkten technische Kommunikationsprobleme zunächst wie die Ursache schlechter Abstimmung. Neue Videotechnik löste das Problem jedoch nicht. Erst als alle relevanten Teammitglieder stärker in strategische Produktdiskussionen einbezogen wurden, verbesserte sich die Zusammenarbeit.
Die Lektion daraus ist wichtig:
Ein schlechtes Daily Scrum ist oft ein Symptom.
Nicht die eigentliche Krankheit.
Wie sieht ein wirklich gutes Daily Scrum aus?
Es gibt keinen perfekten Ablauf für jedes Team.
Aber vier Ergebnisse sollten nach einem Daily klar sein.
1. Wissen wir, wo wir beim Sprint-Ziel stehen?
Nicht nur:
Wie viele Tickets sind fertig?
Sondern:
Können wir das vereinbarte Ergebnis des Sprints noch erreichen?
2. Wissen wir, was heute am wichtigsten ist?
Das Team sollte nach dem Daily gemeinsame Prioritäten besitzen.
3. Haben wir kritische Hindernisse erkannt?
Zum Beispiel:
- fehlende Entscheidung
- technische Blockade
- Abhängigkeit zu einem anderen Team
- fehlende Information
- Überlastung
- zu viel parallele Arbeit
4. Hat sich daraus ein konkreter Plan ergeben?
Wenn nach dem Daily alles exakt so weiterläuft wie vorher, war das Meeting möglicherweise unnötig.
Das Daily ist ein Inspect-and-Adapt-Event.
Inspektion ohne Anpassung reicht nicht.
Ein besserer Ablauf für das Daily Scrum
Teams, die ihr Daily verbessern möchten, können folgende Struktur testen.
Frage 1: Was ist unser Sprint-Ziel?
Nicht jedes Team muss es täglich vorlesen.
Aber jeder sollte wissen, worauf die Arbeit ausgerichtet ist.
Frage 2: Wie sicher sind wir, dass wir es erreichen?
Zum Beispiel:
- sicher
- gefährdet
- derzeit unwahrscheinlich
Keine komplizierte Kennzahl.
Nur eine ehrliche Einschätzung.
Frage 3: Welche begonnene Arbeit müssen wir zuerst abschließen?
Gehe nicht zuerst Person für Person durch.
Gehe durch die Arbeit.
Am besten von fast fertig zu noch nicht begonnen.
Frage 4: Wo brauchen wir Zusammenarbeit?
Zum Beispiel:
„Kann jemand heute beim Test unterstützen, damit dieses Item abgeschlossen wird?“
Frage 5: Was blockiert das Sprint-Ziel?
Nicht jedes kleine Problem ist ein echtes Hindernis.
Konzentriere dich auf Themen, die den gemeinsamen Fortschritt beeinflussen.
Frage 6: Was ändern wir heute konkret?
Das ist die entscheidende Frage.
Ohne Veränderung gab es wenig echte Adaptation.
Welche Rolle hat der Product Owner im Daily Scrum?
Der Product Owner muss das Daily Scrum nicht als Kontrollinstanz besuchen.
Nach dem Scrum Guide ist das Event für die Developer. Product Owner und Scrum Master nehmen dann als Developer teil, wenn sie selbst aktiv an Einträgen des Sprint Backlogs arbeiten.
Das bedeutet nicht, dass Product Owner und Developer nur einmal täglich miteinander sprechen dürfen.
Im Gegenteil.
Fragen zu:
- Scope
- Priorisierung
- Anforderungen
- Produktentscheidungen
sollten dann geklärt werden, wenn sie entstehen.
Scrum.org betont ausdrücklich, dass das Daily nicht der einzige Zeitpunkt ist, an dem ein Team seinen Plan anpasst oder miteinander kommuniziert.
Ein Team, das bis zum nächsten Morgen wartet, obwohl um 11 Uhr ein kritischer Blocker entsteht, hat Scrum missverstanden.
Die häufigsten Fehler im Daily Scrum
Jeder berichtet an den Scrum Master
Dadurch entsteht Statuskommunikation statt Selbstmanagement.
Die drei Fragen werden mechanisch abgearbeitet
Eine mögliche Technik wird mit dem Zweck des Events verwechselt.
Manager kontrollieren individuelle Leistung
Dann optimieren Menschen ihre Statusmeldung statt ihre Zusammenarbeit.
Das Sprint-Ziel fehlt
Das Team besitzt keinen gemeinsamen Bezugspunkt.
Jeder arbeitet an seinem eigenen Ticket
Das Daily kann fehlende Zusammenarbeit nicht durch Kommunikation ersetzen.
Blocker werden nur genannt
„Ich bin seit drei Tagen blockiert“ ist keine sinnvolle Routine.
Es braucht eine Konsequenz.
Jede Diskussion wird sofort beendet
Die 15-Minuten-Timebox darf nicht dazu führen, relevante Zusammenarbeit zu verhindern. Detailarbeit findet anschließend statt.
Jedes Problem wird sofort mit allen gelöst
Dadurch werden unbeteiligte Teammitglieder gebunden.
Das Board wird nur vorgelesen
Informationen, die jeder bereits sehen kann, müssen nicht verbal wiederholt werden.
Wann ist das Daily Scrum wirklich Zeitverschwendung?
Das Daily Scrum liefert wenig Nutzen, wenn:
- es kein gemeinsames Sprint-Ziel gibt
- Teammitglieder überwiegend unabhängig voneinander arbeiten
- Entscheidungen ausschließlich durch Vorgesetzte getroffen werden
- das Sprint Backlog faktisch nicht angepasst werden darf
- jeder nur persönliche Aufgaben berichtet
- Probleme bekannt sind, aber niemand handelt
- Transparenz unerwünscht ist
- das Team keinerlei Selbstmanagement besitzt
Dann hilft auch die beste Moderationstechnik wenig.
Besonders wichtig:
Wenn die Arbeit grundsätzlich nicht zu Scrum passt, sollte ein Unternehmen nicht versuchen, das Daily Scrum künstlich zu retten.
Scrum wurde für komplexe Arbeit entwickelt, bei der ein Team gemeinsam auf ein Ziel hinarbeitet und regelmäßig inspect and adapt betreibt. Wenn eine Gruppe dagegen überwiegend unabhängige Standardaufgaben abarbeitet, kann eine andere Arbeits- und Koordinationsform sinnvoller sein. Auch Scrum.org weist darauf hin, dass ein Daily wenig Mehrwert erzeugt, wenn Mitarbeitende im Grunde getrennte Arbeitsströme bearbeiten.
Wie misst man, ob ein Daily Scrum funktioniert?
Nicht über die Meetingdauer allein.
Und auf keinen Fall über die Zahl der Wortmeldungen.
Beobachte stattdessen über mehrere Sprints:
- Wie häufig wird das Sprint-Ziel erreicht?
- Werden Blockaden früher erkannt?
- Wie lange bleiben kritische Hindernisse ungelöst?
- Sinkt die Menge gleichzeitig begonnener Arbeit?
- Arbeiten Teammitglieder häufiger gemeinsam an kritischen Items?
- Wird weniger Arbeit in den nächsten Sprint übertragen?
- Werden Probleme zwischen den Teammitgliedern direkt gelöst?
- entstehen aus dem Daily konkrete Planänderungen?
- werden zusätzliche Abstimmungsmeetings reduziert?
Der Scrum Guide beschreibt als erwarteten Nutzen unter anderem bessere Kommunikation, frühere Identifikation von Hindernissen und schnellere Entscheidungen.
Genau daran sollte sich der Nutzen zeigen.
Nicht daran, ob alle pünktlich drei Fragen beantwortet haben.
So verbessert ihr das Daily Scrum im Unternehmen
Eine pragmatische Verbesserung braucht keine neue Scrum-Schulung für das ganze Unternehmen.
Startet mit einem Team.
Schritt 1: Zweck erneut klären
Jedes Teammitglied sollte erklären können:
Warum machen wir dieses Daily überhaupt?
Schritt 2: Drei-Fragen-Ritual für zwei Sprints aussetzen
Nicht weil die Fragen grundsätzlich falsch sind.
Sondern weil Routinen bewusst unterbrochen werden müssen.
Schritt 3: Sprint-Ziel ins Zentrum stellen
Beginnt mit:
„Wie stehen wir zum Sprint-Ziel?“
Schritt 4: Arbeit statt Personen betrachten
Geht durch den Sprint Backlog.
Konzentriert euch zuerst auf bereits begonnene Arbeit.
Schritt 5: Blockaden mit Konsequenzen versehen
Für jedes relevante Hindernis muss anschließend klar sein:
- Wer kümmert sich?
- Wer muss unterstützen?
- wann wird weitergearbeitet?
Schritt 6: Detaildiskussionen auslagern
Nach dem Daily bleiben nur die Personen zusammen, die tatsächlich gebraucht werden.
Schritt 7: Nach zwei Sprints überprüfen
Fragt in der Retrospektive:
- Hilft uns das Daily bei der Planung?
- erkennen wir Probleme früher?
- arbeiten wir stärker zusammen?
- Was können wir weglassen?
- Was sollten wir verändern?
Das ist Scrum in seiner eigentlichen Logik:
Transparenz. Inspektion. Anpassung.
Auch beim Scrum selbst.
Muss ein Daily Scrum immer exakt 15 Minuten dauern?
Nein.
15 Minuten sind die Timebox.
Das Team muss die Zeit nicht künstlich füllen.
Wenn der Zweck nach acht oder zehn Minuten erreicht ist, kann das Event enden. Scrum.org weist ausdrücklich darauf hin, dass Scrum Events früher beendet werden können, sobald ihr Zweck erfüllt wurde.
Wenn ein Team dagegen dauerhaft deutlich mehr Zeit benötigt, sollte es die Ursache untersuchen.
Mögliche Gründe:
- zu großes Team
- zu viel parallele Arbeit
- fehlender Fokus
- lange Problemdiskussionen
- schwaches Sprint-Ziel
- zu viele Abhängigkeiten
Das Problem lautet dann nicht:
„Wir müssen schneller sprechen.“
Sondern:
„Warum benötigen wir so viel Koordination?“
Muss man beim Daily Scrum stehen?
Nein.
Der verbreitete Begriff „Daily Stand-up“ führt hier in die Irre.
Stehen ist keine Scrum-Regel.
Scrum.org weist ausdrücklich darauf hin, dass das Event Daily Scrum heißt und niemand stehen muss.
Ob ein Team steht, sitzt oder sich virtuell trifft, ist nebensächlich.
Relevant ist:
Entsteht ein besserer Plan für das Erreichen des Sprint-Ziels?
Häufige Fragen zum Daily Scrum
Was ist das Ziel eines Daily Scrums?
Das Team überprüft seinen Fortschritt zum Sprint-Ziel und passt seinen Plan für die bevorstehende Arbeit an. Das Sprint Backlog kann dabei verändert werden.
Wer muss am Daily Scrum teilnehmen?
Das Daily Scrum ist ein Event für die Developer. Product Owner oder Scrum Master nehmen als Developer teil, wenn sie selbst aktiv an Einträgen des Sprint Backlogs arbeiten.
Muss der Scrum Master das Daily moderieren?
Nein. Die Developer führen das Daily Scrum selbst durch. Der Scrum Master unterstützt dabei, das Event und dessen Zweck richtig zu verstehen.
Sind die drei Daily-Fragen Pflicht?
Nein. Die früher verbreiteten drei Fragen wurden im Scrum Guide 2020 entfernt. Teams dürfen ihre eigene Struktur wählen.
Darf ein Daily Scrum kürzer als 15 Minuten sein?
Ja. Die Timebox beträgt maximal 15 Minuten. Wenn der Zweck früher erreicht ist, kann das Event beendet werden.
Was passiert mit Problemen, die länger diskutiert werden müssen?
Sie werden im Daily sichtbar gemacht. Die benötigten Personen können anschließend unmittelbar weiterarbeiten. Nicht jedes Teammitglied muss an jeder Detaildiskussion teilnehmen.
Kann man das Daily Scrum abschaffen?
Wer Scrum vollständig einsetzt, entfernt damit einen definierten Bestandteil des Frameworks. Bevor ein Team das Daily streicht, sollte es deshalb prüfen, warum das Event keinen Wert erzeugt. Häufig zeigen schlechte Daily Scrums tiefere Probleme bei Sprint-Zielen, Zusammenarbeit oder Selbstmanagement.
Fazit
Daily Scrum ist Zeitverschwendung – oder doch nicht?
Beides ist möglich.
Ein Daily, bei dem sieben Menschen nacheinander erzählen, was sie gestern gemacht haben, kann tatsächlich wenig Mehrwert bieten.
Vor allem dann, wenn jeder anschließend exakt so weiterarbeitet wie vorher.
Das ist aber nicht die Idee des Daily Scrums.
Ein funktionierendes Daily ist eine kurze gemeinsame Planung.
Das Team überprüft:
Wo stehen wir?
Gefährdet etwas unser Sprint-Ziel?
Was müssen wir heute gemeinsam fertigstellen?
Was ändern wir an unserem bisherigen Plan?
Dafür braucht es keine perfekten drei Fragen.
Keine tägliche Moderation durch den Scrum Master.
Und schon gar keinen Statusbericht für das Management.
Es braucht ein echtes gemeinsames Ziel und ein Team, das Verantwortung für seine Arbeit übernimmt.
Wenn ein Daily Scrum langweilig, redundant oder bedeutungslos wirkt, sollte deshalb nicht zuerst gefragt werden:
„Wie machen wir das Meeting interessanter?“
Die bessere Frage lautet:
„Was verhindert gerade, dass wir diese 15 Minuten für eine echte gemeinsame Entscheidung nutzen?“
Genau dort beginnt die Verbesserung.
PURE Consultant unterstützt Unternehmen und Scrum Teams dabei, agile Arbeitsweisen nicht nur formal einzuführen, sondern auf tatsächliche Zusammenarbeit, klare Ziele und wirksames Selbstmanagement auszurichten. Denn Scrum erzeugt seinen Wert nicht durch Termine im Kalender, sondern durch bessere Entscheidungen und bessere Ergebnisse.