Daily Standup — was es ist, Regeln für das tägliche Meeting und Nutzen

Was ist das Daily Standup?

Daily Standup — ein kurzes Meeting des Scrum-Teams, das jeden Werktag zur gleichen Zeit und am gleichen Ort stattfindet. Timebox — 15 Minuten. Es ist unter verschiedenen Namen bekannt: Daily Scrum (im Scrum Guide), Morgen-Synchronisation, Morning Circle, Daily. Ziel ist es, das Team zu synchronisieren, Blocker zu identifizieren und die Tagespläne anzupassen. Das Daily ist kein Bericht für den Manager, sondern ein Werkzeug zur Selbstorganisation des Teams. Das Team entscheidet, wie das Meeting strukturiert wird, nicht der Manager.

Der Ursprung des Begriffs „Standup" kommt von der Praxis, während des Meetings buchstäblich zu stehen: Die Teilnehmer versammeln sich um das Board und setzen sich nicht. Das schafft ein Gefühl der Zeitlichkeit — niemand möchte länger als 15 Minuten stehen. Physisches Standup wird noch von 60% der Teams genutzt (laut Scrum.org 2025), der Rest ist auf Remote-Format via Zoom, Slack Huddle oder Teams umgestiegen. Im Remote-Format ist es wichtig, Disziplin zu wahren: Kameras an, keine Multitasking, vorheriges Durchdenken der Antworten.

Der Scrum Guide 2025 definiert das Daily Scrum als ein Event für Developers (Entwickler). Product Owner und Scrum Master können teilnehmen, sind aber nicht dazu verpflichtet. Wenn PO oder SM teilnehmen, leiten sie das Meeting nicht. Das Team wählt seine eigene Struktur: die klassischen drei Fragen oder einen Board Walk. Schlüsselpunkt: Das Daily dient der Inspektion des Fortschritts in Richtung Sprint Goal, nicht dem Status jeder einzelnen Aufgabe. Wenn das Meeting zu einer Aufzählung von Aufgaben auf dem Board wird, hat das Team den Fokus auf das Sprint Goal verloren.

Die drei Fragen des Daily Standup

Frage 1: „Was habe ich gestern getan, um das Sprint Goal zu erreichen?" — eine kurze Zusammenfassung der erledigten Aufgaben. Nicht „ich habe an APP-123 gearbeitet", sondern „den Login-Bildschirm fertiggestellt, PR zur Überprüfung gesendet". Die Formulierung „um das Sprint Goal zu erreichen" ist bewusst gewählt: Sie verbindet die tägliche Arbeit mit dem Gesamtziel des Sprints. Wenn ein Entwickler keinen Zusammenhang zwischen seiner Aufgabe und dem Sprint Goal sieht, ist das ein Signal, dass die Aufgabe im aktuellen Sprint möglicherweise nicht benötigt wird. In der mobilen Entwicklung umfassen die gestrigen Ergebnisse nicht nur Code, sondern auch Tests, Dokumentation und CI/CD-Konfiguration.

Frage 2: „Was habe ich heute vor, um das Sprint Goal zu erreichen?" — der Plan für den aktuellen Tag. Nicht mehr als 2-3 Punkte. Ein Entwickler könnte sagen: „Heute werde ich die ViewModel für den Profilbildschirm fertigstellen, Unit-Tests schreiben und einen Build auf einem echten Gerät durchführen." Wenn der Plan mit dem von „gestern" übereinstimmt, ist das ein Signal, dass die Aufgabe zu groß ist und zerlegt werden muss. Die Zwei-Tage-Regel: Wenn eine Aufgabe nicht innerhalb von 2 Arbeitstagen abgeschlossen ist, sollte sie in Teilaufgaben aufgeteilt werden, sonst bleibt sie wochenlang in In Progress hängen.

Frage 3: „Welche Blocker behindern meinen Fortschritt?" — die wichtigste Frage. Ein Blocker ist etwas, das der Entwickler nicht selbst lösen kann: Warten auf eine Überprüfung (wenn die Review-SLA überschritten ist), ein defekter Emulator, eine nicht fertige API, benötigter Zugriff auf das Repository. Wichtig: Blocker sollten genannt, aber nicht während des Daily gelöst werden. Nach dem Meeting vereinbaren der Entwickler und der Scrum Master / Manager die Lösung des Blockers. Laut Scrum.org (2025) hängen 70% der Blocker mobiler Teams mit Folgendem zusammen: Warten auf Reviews (30%), Nichtverfügbarkeit von Testgeräten (20%) und Abhängigkeiten vom Backend (20%).

Wie man ein Standup richtig durchführt

Zeit und Ort. Das Daily findet jeden Tag zur gleichen Zeit statt — normalerweise zu Beginn des Arbeitstages (9:00-10:00). Für verteilte Teams wird eine für alle Zeitzonen angenehme Zeit gewählt. Dauer — strikt 15 Minuten. Ein Timer ist obligatorisch. Wenn das Team nicht rechtzeitig fertig wird, liegt das Problem nicht am Daily, sondern am Prozess: entweder zu viele Teilnehmer oder es werden Aufgaben diskutiert statt nur genannt. Die Ping-Pong-Regel: Jeder Teilnehmer spricht nicht länger als 60 Sekunden. Nach der Antwort gibt er das Wort an den Nächsten weiter.

Board Walk-Format. Eine Alternative zu den drei Fragen: Das Team bewegt reihum Aufgaben auf dem Scrum-Board und kommentiert die Änderungen. Ein Entwickler nimmt seine Aufgabe aus To Do, verschiebt sie in In Progress und sagt: „Ich nehme APP-123 — den Bestellbildschirm, füge ein Promo-Code-Feld hinzu." Board Walk bietet ein visuelles Verständnis des Fortschritts und deckt „vergessene" Aufgaben auf — solche, die seit 3+ Tagen unberührt sind. Board Walk ist vorzuziehen für verteilte Teams mit Jira/Linear — alle sehen das Board, anstatt einem Monolog zu lauschen.

Für Remote-Teams: Kameras müssen eingeschaltet sein — laut Microsoft Research (2025) erhöht eine eingeschaltete Kamera das Engagement um 40%. Nutzen Sie einen gemeinsamen Bildschirm mit dem Aufgabenboard (Jira, Linear, Miro). Schreiben Sie Blocker in den Chat — das schafft eine schriftliche Aufzeichnung. Fördern Sie Reaktions-Emojis (außer bei Anweisung des Benutzers — Emojis werden nicht verwendet) — ein Daumen hoch auf die Nachricht eines Kollegen. Nehmen Sie sich nach dem Daily 2-3 Minuten für den Parkplatz (Parking Lot): Themen, die eine separate Diskussion erfordern, werden in eine Liste für Folgetreffen aufgenommen. Schlüsselkompetenz des Scrum Masters: die Diskussion während des Daily zu stoppen und auf den Parkplatz zu verschieben.

Typische Fehler bei der Durchführung

Fehler 1: Statusbericht für den Manager. Die Entwickler lesen reihum vor, was in Jira steht, der Manager stellt Rückfragen, das Meeting dauert 45 Minuten. Lösung: Daran erinnern, dass das Daily für das Team ist, nicht für den Manager. Der Manager kann den Status auf dem Board einsehen. Wenn der Manager Fragen stellt, verschieben Sie diese in 1:1-Meetings. Ein Team, das das Daily in einen Statusbericht verwandelt, verliert 2-3 Stunden pro Woche über alle Teilnehmer hinweg. Bei 8 Entwicklern sind das 16-24 Personenstunden pro Monat — der Verlust eines ganzen Sprints im Jahr.

Fehler 2: Probleme vor Ort lösen. Ein Entwickler sagt „Ich habe einen Bug mit gRPC — das Projekt baut nicht" und das gesamte Team diskutiert 20 Minuten lang Lösungen. Lösung: Den Blocker im Parkplatz notieren und das Daily fortsetzen. Nach dem Meeting die relevanten Personen (Entwickler + wer helfen kann) zu einer 10-minütigen Diskussion zusammenrufen. Laut Basecamp (Shape Up) erfordern nur 20% der im Daily entdeckten Probleme eine Diskussion des gesamten Teams. Der Rest wird von zwei Entwicklern in 10 Minuten gelöst.

Fehler 3: Verspätungen und Abwesenheit. Jemand kommt 5 Minuten nach Beginn und alles muss wiederholt werden. Lösung: Die Regel aufstellen, dass „das Daily pünktlich beginnt, Nachzügler nicht teilnehmen" oder „der Zuspätkommende zahlt eine Strafe" (Kaffee fürs Team). Noch strenger: Das Daily findet zu einer festen Zeit statt; wenn jemand systematisch zu spät kommt, ist das ein Disziplinproblem, das im 1:1 gelöst wird. Das Daily ist die Synchronisation des Tages. Wenn ein Entwickler es verpasst, ist er nicht synchronisiert und riskiert, die falsche Arbeit für das Team zu erledigen.

Fehler 4: Zu viele Teilnehmer. Ein Team von 15+ Personen, jeder spricht eine Minute — insgesamt 20+ Minuten. Lösung: Teilen Sie das Team in Untergruppen nach Funktion/Modul auf. Jede Untergruppe hält ihr eigenes Daily ab (5-7 Personen). Ein Vertreter jeder Untergruppe kann an einem teamübergreifenden Standup teilnehmen (wenn Synchronisation zwischen Teams erforderlich ist). Alternative: Ein asynchrones Standup via Slack/GeekBot, bei dem jeder schreibt, was er getan hat / plant / Blocker hat.

Asynchrones Standup: Alternativen

Asynchrones Standup — ein Format, bei dem die Teilnehmer ihre Antworten in einen Chat (Slack, Telegram, Teams) oder einen spezialisierten Bot (GeekBot, Standuply, Status Hero) schreiben, anstatt sich mündlich zu treffen. Geeignet für verteilte Teams mit einem Zeitunterschied von 3+ Stunden. Jeder Teilnehmer beantwortet die gleichen drei Fragen bis zu einer bestimmten Uhrzeit (z. B. bis 11:00 Uhr). Der Bot sammelt die Antworten und veröffentlicht eine Zusammenfassung im gemeinsamen Kanal. Vorteile: Flexibilität, schriftliche Aufzeichnung, keine Verspätungsprobleme.

Nachteile des asynchronen Formats: keine Live-Kommunikation — nonverbale Signale gehen verloren, Blocker sind schwieriger zu identifizieren (ein Entwickler schreibt möglicherweise nicht über ein Problem). Ein im Chat geschriebener Blocker kann bis zum Ende des Tages unbemerkt bleiben. Laut GitLab (2025) kehrten 40% der Teams, die auf asynchrones Standup umgestellt haben, innerhalb von 3 Monaten zum mündlichen Standup zurück. Empfehlung: Nutzen Sie ein Hybrid-Modell — 3 Tage mündliches Standup (Mo, Mi, Fr), 2 Tage asynchron (Di, Do). Oder: mündliches Standup 1-2 Mal pro Woche, an den restlichen Tagen asynchron.

Werkzeuge für asynchrones Standup: GeekBot (Slack) — stellt die drei Fragen und veröffentlicht eine Zusammenfassung; Standuply — integriert sich in Jira und bietet automatisches Tracking; Status Hero — sammelt Statusmeldungen und erstellt wöchentliche Berichte für das Management. Die Wahl des Werkzeugs hängt von der Teamkultur ab: In Startups reicht ein Slack-Bot aus; in Unternehmensumgebungen ist möglicherweise Standuply mit Integration in Unternehmensprozesse erforderlich. Wichtige Regel: Unabhängig vom Format sollten die Antworten für das gesamte Team sichtbar sein, nicht nur für den Manager. Transparenz ist ein Kernwert von Agile.

Besonderheiten des Daily für mobile Teams

Ein mobiles Team steht im Daily vor spezifischen Blockern. Die wichtigsten: Projekt-Build in CI (Gradle-Build kann 20+ Minuten dauern — wenn er bricht, verliert der Entwickler eine Stunde mit Debuggen), Warten auf TestFlight / Firebase App Distribution (Veröffentlichung eines Builds für Tester dauert 30-60 Minuten), Probleme mit Emulatoren und Simulatoren (Android Emulator benötigt KVM/HAXM, iOS Simulator nur auf Mac). Das Daily eines mobilen Teams sollte eine schnelle Build-Statusprüfung beinhalten: „Läuft der Build? Sind alle Tests grün?"

Bei plattformübergreifenden Projekten (Flutter, React Native) kann das Daily eine Frage zum Zustand des gemeinsam genutzten Codes enthalten. Wenn zwei Entwickler gleichzeitig dieselbe Dart-Datei bearbeiten und einer Änderungen zusammenführt, wird der zweite mit Konflikten konfrontiert. Tipp: Verwenden Sie Board Walk mit einem nach Plattform segmentierten Board (Android / iOS / Shared). Dies hilft zu visualisieren, wer wo arbeitet und ob sich Änderungen überschneiden. Verwenden Sie für Flutter-Projekte ein Board mit Spalten für Platform Channel, BLoC/Cubit, UI und Tests.

Release-Bereitschaft ist ein weiterer für die mobile Entwicklung spezifischer Punkt im Daily. Fügen Sie 3-5 Tage vor dem Release die Frage hinzu: „Ist der Build für das Release bereit? Sind alle Metadaten (Icons, Screenshots, Beschreibungen) aktualisiert?" Dies verhindert Situationen, in denen Entwickler am Release-Tag mit dem Codieren fertig werden, während Build und Veröffentlichung weitere 3-4 Stunden dauern. Release-Tracker — ein separates Board mit einer Checkliste: versionCode/versionName aktualisieren, ProGuard prüfen, AAB signieren, in die Entwicklerkonsole hochladen, Release-Notes schreiben.