Daily Scrum

English
Daily Scrum

Das Daily Scrum ist ein 15-minütiges Meeting für das Scrum Team. Es findet an jedem Arbeitstag statt, im Normalfall zur gleichen Zeit am gleichen Ort. Das Treffen dient dem Team dazu, die Tätigkeiten im Zeitraum bis zum nächsten Daily Scrum zu teilen, zu planen und mögliche Hindernisse ("Impediments") im Team zu kommunizieren, um notwendige Aktionen möglichst sofort einzuleiten. Daily Scrum zählt wie Sprint Planning, Sprint Review und Sprint Retrospektive zu den Scrum Events.

Daily Scrum

Daily Scrum

English
Daily Scrum

Das Daily Scrum ist ein 15-minütiges Meeting für das Scrum Team. Es findet an jedem Arbeitstag statt, im Normalfall zur gleichen Zeit am gleichen Ort. Das Treffen dient dem Team dazu, die Tätigkeiten im Zeitraum bis zum nächsten Daily Scrum zu teilen, zu planen und mögliche Hindernisse ("Impediments") im Team zu kommunizieren, um notwendige Aktionen möglichst sofort einzuleiten. Daily Scrum zählt wie Sprint Planning, Sprint Review und Sprint Retrospektive zu den Scrum Events.

Daily Scrum
Wir empfehlen zum Thema Scrum
Zertifizierter Product Owner und Scrum Master

Lassen Sie sich in einem nur 3-tägigen, kombinierten Praxistraining zum Product Owner und zum Scrum Master zertifizieren.  Mehr Infos

Einsatzmöglichkeiten

  • Das Daily Scrum ist ein fester Bestandteil im Scrum Framework
  • Das Daily Scrum eigenet sich auch in anderen Vorgehensmodellen dafür, dass sich die Teammitglieder austauschen und Arbeitspakete miteinander abstimmen.
  • In langen Workshops bietet das Format Daily Scrum die Möglichkeit, einen Zwischenstatus des Gesamtfortschritts festzuhalten und nächste Schritte innerhalb der Workshop-Übungen zu planen.

 

Ergebnisse

  • Das Team ist über den aktuellen Forschritt bezüglich des Sprint-Zieles informiert.
  • Fachliche Rückfragen wurden im Team geklärt, bzw. die Klärung wurde eingeleitet.
  • Vereinbarte Maßnahmen zur Behebung von Problemen bei der Umsetzung der Sprint-Ziele (“Impediments”) wie z.B. Pair-Programming, Arbeitsgruppen, Trainings- oder Umsetzungs-Dojos, Weiterbildungen, Coaching.

Vorteile

Die teilnehmenden Personen bleiben durch den straffen, 15-minütigem Ablauf konzentriert und schweifen nicht ab.
Die Behandlung aktueller Themen ermöglicht eine fokussierte Planung kurzer Zeiträume (i.d.R. 1 Tag).
Das einfache Regelwerk des Daily Scrums ermöglicht es einem stabilen Teilnehmerkreis, sich auch ohne Moderation weitgehend selbst zu organisieren.

Durchführung: Schritt für Schritt

Das Daily Scrum wird im Rahmen des Scrum Frameworks mit dessen Nomenklatur beschrieben (s.u. Herkunft). Zum besseren Verständnis definiere ich zunächst einige wichtige Begriffe und erkläre, wie ich sie in hier verwende.

Aus Gründen der einfacheren Lesbarkeit wird im Folgenden nur die grammatikalisch männliche Form (Scrum Master, Product Owner, Moderator) verwendet. Es sind dabei aber stets Personen jeden Geschlechts gemeint.

  • Der Scrum Master als Facilitator des Scrum-Vorgehens ist unter anderem für die Moderation der Scrum Events verantwortlich. In Absprache mit ihm kann auch ein anderes Teammitglied die Moderation übernehmen.
    Im Folgenden verwende ich deshalb allgemein den Begriff "Moderator" bzw. "Moderation". Den Begriff "Scrum Master" benutze ich, wenn es um eindeutig dem Scrum Master zugeordnete Tätigkeiten geht.
  • Der Product Owner vertritt die Auftraggeberseite und gibt gegenüber dem Team das "Was" vor. D.h. er benennt die Aufgaben, die das Team eigenverantwortlich lösen soll. Er stellt am Ende eines festgelegten, wiederkehrenden Zeitraums (Sprint, s.u.) die Zielerreichung fest und ist unter anderem erster Ansprechpartner für fachliche Rückfragen aus dem Team.
  • Sprint ist der festgelegte, wiederkehrende Zeitraum, in dem das Team die Aufgaben umsetzt. Die Dauer eines Sprints beträgt meist vier Wochen, sie kann aber auch kürzer oder länger festgelegt werden. Innerhalb eines Sprints finden festgelegte Events wie das Daily Scrum statt.
  • Aufgabe (Task), Bug, User Story, Epic: Diese sogenannten "Artefakte" sind Gegenstände oder Informationsspeicher, die in den Sprints vom Team bearbeitet werden. Sie haben unterschiedliche Größenordnung und Relevanz. Während Bugs und Aufgaben die kleinste Einheit darstellen, besteht eine User Story aus mehreren Aufgaben und ein Epic aus mehreren User Storys.
  • Ein Backlog beschreibt eine priorisierte Liste von Epics oder User Storys. Das Backlog wird vom Product Owner verwaltet. Je nach Scrum-Anwendung gibt es ein oder mehrere Backlogs wie z.B. Product Backlog, Sprint Backlog oder Epic Backlog. Bei gleichzeitigem Einsatz sind diese Backlogs Teilmengen voneinander (Beispiel: Ein Sprint Backlog ist diejenige Teilmenge des Product Backlogs, die im Sprint umgesetzt werden soll).
  • Das Sprint-Ziel ist eine kurz und präzise forumulierte Zusammenfassung des Sprint Backlogs, d.h. der Aufgaben des aktuellen Sprints.
  • Scrum Team und Entwicklungsteam (Development Team): In Scrum wird die Personengruppe, die direkt an der Umsetzung der geplanten Tätigkeiten im Sprint beteiligt ist, "Entwicklungsteam" genannt, unabhängig davon, ob es sich tatsächlich um Entwicklungstätigkeiten handelt. Es geht vielmehr um die Umsetzung der geplanten User Storys. Der Begriff "Scrum Team" schließt Scrum Master und Product Owner mit ein.
    In diesem Artikel verwende ich durchgängig den Begriff "Team" für "Scrum Team" und spreche einzelne Rollen je nach Bedarf gezielt an.
  • Eine Timebox ist ein vorab festgelegter Zeitraum, in dem anhand einer ausgereiften Methodik Wertschöpfung stattfindet. In Scrum wird dem Einhalten von Timeboxen ein hoher Stellenwert zugeschrieben. Alle Scrum Events, so auch das Daily Scrum, bestehen aus einer oder mehrerer Timeboxen. Die größte Timebox des Daily Scrums besteht aus seiner gesamten Dauer von 15 Minuten. Kleine Timeboxen können im Daily Scrum beispielsweise Gesprächs- oder Themen-Timeboxen sein.

Schritt 1: Der Moderator eröffnet das Daily Scrum

Pünktlich zum geplanten Beginn des Daily Scrum beginnt die Moderation mit der Einleitung des Meetings. Falls Teammitglieder fehlen, stellt die Moderation klar, dass ein Scrum Event stets pünktlich beginnt und keine Rücksicht auf fehlende Einzelpersonen genommen werden kann. Dies dient im gewissen Sinne der Erziehung zur Pünktlichkeit.

Die Moderation erklärt, dass das Daily Scrum ein Teamevent ist, in dem die Teammitglieder

  • sich austauschen, um einen thematischen Überblick zu erhalten,
  • Schwierigkeiten aufdecken, um sie gesondert, aber gemeinsam zu lösen
  • eine Prognose zur Bearbeitung der offenen User Storys abgeben, damit der Product Owner frühzeitig mögliche Optionen gemeinsam mit dem Team abwägen und verabschieden kann.

Die Moderation klärt ab, wie der Austausch erfolgen soll: Thematisch geordnet, reihum oder mit Wortmeldungen. Diese Abfrage ist nicht bei jedem Daily notwendig, jedoch lohnt sich ein Wechsel zwischendurch. Das sorgt nicht nur für Abwechslung, sondern unterstützt ebenfalls das Vermeiden einer Berichtsroutine.

Zur Vermeidung eingefahrener Abläufe gehört ebenfalls die Abhaltung im Stehen. Das Daily Scrum ist ein sogenanntes "Standup Meeting", d.h. während der 15 Minuten steht das gesamte Team (soweit physikalisch möglich) im Idealfall im Kreis oder im Halbkreis um die Moderationsfläche oder das Kanban-Board.

Aufgabengebiete

Alle Kommentare (2)

Guest

Vielleicht wäre erwähnenswert, dass es zwei wesentliche Alternativen gibt, wie die Reihenfolge des Redners bestimmt wird: 1. Personen-zentriert (also z. B. einfach reihum) 2. (Sprint-)Themen-zentriert (also gemäß Reihenfolge der abzuarbeitenden Aktivitäten) (1) bietet den Vorteil, dass auch ruhige Teilnehmer über ihren Stand, ihre nächsten Schritte und Hindernisse aktiviert werden. Ein Nachteil ist, dass evtl. thematisch gesprungen wird, je nachdem an welchem Thema der jeweils aktive Teilnehmer arbeitet. (2) bietet den Vorteil, dass weiterhin ergebnis-fokussiert bis zum nächsten Daily geplant wird. Damit bleibt das Team "länger" in einem Thema. Nachteil, ruhige oder introvertierte Teilnehmer können benachteiligt werden bzw. sich auch leichter "entziehen". Hier ist also der Moderator/Facilitator gefragt. Aus eigener Erfahrung als Scrum Master kann ich sagen: (1) ist ein guter Start, um zu gewähleisten, dass sich alle beteiligen und die Disziplin erlernen kurz und prägnant zu formulieren. (2) unterstützt wesentlich besser den Fokus zu halten und liefert auch aus Sicht (zumindest meiner) Teams die bessere Effektivität. Es erfordert allerdings eine höhere Disziplin bei den Beteiligten und häufig eine gute Moderation, da sich Leute leichter in Diskussionen des jeweils aktuellen Themas verlieren können. Inwieweit (2) auch gut in anderen Umgebungen als Scrum mit seinen themenbegrenzenden Sprints funktioniert, weiß ich nicht. Denn wenn 8 Leute an 8 unterschiedlichen Themen arbeiten unterscheidet sich (2) nicht mehr von (1) ...

 

Dieter
Bertsch

…und noch ein paar Ergänzungen/Anmerkungen:
&nbsp
Lehrbuch: - Product Owner (PO) & ScrumMaster (SM) müssen nicht teilnehmen; SM muss dafür sorgen, dass es stattfindet - Öffentliches Meeting, an dem jeder teilnehmen darf; jedoch nur Mitglieder des Development Teams dürfen etwas sagen
&nbsp
Praxis: - PO & SM sollten teilnehmen und auch einen Redebeitrag über ihren Anteil zur Erreichung des Sprint Ziel haben - Letzte Statement der drei zu beantwortenden Fragen vorziehen: Erst sagen, welche Hindernisse da sind bevor man mitteilt, was man als nächstes tuen will - Große Gefahr bei der Aktualisierung des Sprint-Backlog bei der Verwendung digitaler Medien: Hier geht oft der Fokus für die Inhalte durch die Beschäftigung mit dem Tool verloren. Tipp: Wenn immer möglich, ein physische Task Board verwenden! - Apropos Task Board: Im Artikel wird mehrfach die Verwendung eines Kanban Boards erwähnt. Kanban ist eine Lean Management-Methode zur Optimierung von Prozessen. Kanban zeichnet sich durch die Limitierung der gleichzeitig in Bearbeitung befindlicher Backlog-Items aus (Work in Progress – WiP). Diese werden als Zahlen (WiP-Limits) über den Spalten des Kanban Boards vermerkt. Scrum fokussiert hingegen auf die Produkterstellung und limitiert die Menge der Arbeit durch Timeboxen (Sprints). Scrum kennt keine WiP-Limits und verwendet deshalb auch nur ein Task Board zur Visualisierung – kein Kanban Board!