Es gibt zwei Backlogs in Scrum.
Sie unterscheiden sich im Planungshorizont und in der Struktur. Das Sprint-Backlog wird häufig als der kleinere Bruder des Product-Backlogs gesehen, und damit sind wir schon beim ersten Fehler:
Fehler 1: Das Sprint-Backlog ist nur ein Teil des Product-Backlogs
Ich glaube, an dieser Fehlvorstellung ist Jira schuld.
Betrachten wir die typische Product-Backlog-Ansicht in Jira.
Wird jetzt ein neuer Sprint in Jira angelegt (siehe 1 im Bild), entsteht ein neues Backlog (siehe 2 im Bild). Dieses neue Backlog für den Sprint wird dann mit Einträgen aus dem unteren Backlog gefüllt. Das führt zu der Vorstellung, das Sprint-Backlog sei nur ein Teil des Product-Backlogs. Dies ist ein Fehler. Das Sprint-Backlog besteht aus den Einträgen des Product-Backlogs, diese werden jedoch einem Ziel, welches das Team in den nächsten 30 Tagen verfolgt, untergeordnet und um einen konkreten Plan, wie dieses Ziel erreicht werden kann, ergänzt.
Der Scrum Guide beschreibt es so:
„Das Sprint-Backlog besteht aus dem Sprint-Ziel (Wofür), den für den Sprint ausgewählten Product-Backlog-Einträgen (Was) sowie einem umsetzbaren Plan für die Lieferung des Inkrements (Wie).“
Beschränken wir das Sprint-Backlog nur auf eine Liste von Product-Backlog-Einträgen, beschränken wir auch die Effektivität des Teams. Wir berauben es der Möglichkeit, sich ein gemeinsames Ziel für die nächsten 30 Tage zu setzen und einen Plan zu erstellen, wie dieses Ziel erreicht werden kann.
Fehler 2: Das Sprint-Backlog besitzt eine „Warten“-Spalte
Über nichts wird in der Scrum- und Kanban-Gemeinde wohl kontroverser diskutiert.
Die Befürworter von „Warten“-Spalten argumentieren, dass diese Spalte die Sichtbarkeit von Blockierungen, Einträgen oder Engpässen im Arbeitsfluss erhöht. Eine „Warten“-Spalte steigert also die Transparenz.
Ich bin anderer Meinung.
Ich habe es bereits mit Scrum Teams ausprobiert und dabei beobachtet:
- Ein junioriger Entwickler übernimmt einen Task. Nachdem er seine Arbeit abgeschlossen hat, wartet er darauf, dass ein anderer Entwickler seine Arbeit prüft. Was macht er also? Er schiebt den Task auf „Warten“.
- Ein Entwickler arbeitet am Frontend. An einer Stelle hat er eine Rückfrage an den Designer, der das Design erstellt hat. Da der Designer nicht Teil des Teams ist und er ihn nicht über Slack erreicht, macht er was? Er schiebt den Task in die „Warten“-Spalte.
In beiden Beispielen gaben sich die Entwickler mit der Situation zufrieden und begannen die Arbeit an einem neuen Task.
Was mich zur Schlussfolgerung bringt:
„Warten“-Spalten in Sprint-Backlogs verschleiern das eigentliche Problem. In meinen Beispielen ist einmal der Arbeitsprozess nicht vollständig visualisiert und beim anderen Mal das Team nicht interdisziplinär aufgestellt und hat deshalb Abhängigkeiten von anderen Teams.
Neben „Warten“-Spalten gibt es noch eine weitere Spalte, die viele Fehlvorstellungen birgt:
Fehler 3: Die „Done“-Spalte beschreibt nur, ob die Arbeit im Team abgeschlossen ist
Der Zweck von Scrum, auf ein Wort reduziert?
Ken Schwabers Antwort: „done“.
In Scrum geht es darum, in weniger als 30 Tagen eine neue Version des Produkts zu erstellen, die so fertig ist, dass sie den Nutzern Vorteile bringen kann und für die Kunden nützlich ist.
Der Scrum Guide beschreibt diese Tatsache so:
„Die Definition of Done ist eine formale Beschreibung des Zustands des Inkrements, wenn es die für das Produkt erforderlichen Qualitätsmaßnahmen erfüllt.“
Damit das Scrum Team dieses Ziel bei seiner Arbeit nie aus den Augen verliert, sollte die „Done“-Spalte des Sprint-Backlogs dieses „Done“ repräsentieren.
Häufig beobachte ich etwas anderes.
Nehmen wir zum Beispiel an, dass die Definition of Done folgende Einträge umfasst:
- Alles ist unter Versionskontrolle.
- Clean Code (Programmierungsstandards eingehalten und Entwurfs- und Designmuster genutzt)
- Unit Tests für alle privaten Funktionen mit 95 % Abdeckung automatisiert
- Unit Tests für alle öffentlichen Funktionen mit 100 % Abdeckung automatisiert
Wenn die Entwickler einen Eintrag des Sprint-Backlogs auf „Done“ setzen, sind diese vier Punkte erfüllt. Damit die neue Version des Produkts aber zum Kunden ausgeliefert werden kann, müssen noch weitere Schritte unternommen werden:
- Integrationstests mit realen Systemen erfolgreich
- Funktionstest für Benutzerszenarien und Use Cases der User Stories automatisiert
- funktioniert auf einem 1024 x 768 Bildschirm
- Design mit den Definitionen des Styleguide abgeglichen
- alle Akzeptanzkriterien des PBI erfüllt
- Benutzerhandbuch aktualisiert
Diese Dinge werden vielleicht vom Product Owner oder von Personen oder Teams außerhalb des Scrum Teams erledigt. Erst wenn diese Arbeiten erledigt sind, erfüllt die neue Version des Produkts die Qualitätsstandards, die für ein Release nötig sind. Also die Definition of Done.
Spätestens jetzt siehst du das Problem:
Ist das erste „Done“ nur ein „Nearly Done“ oder nur die „Team Definition of Done“? Ist das zweite „Done“ dann ein „Done Done“ oder die „Product Definition of Done“? Wenn es mehrere Beschreibungen von „Done“ gibt, dann führt dies zu Verwirrungen. Mehr noch: Es führt zu falschen Vorstellungen bei den Stakeholdern: „Es ist doch fertig, warum kann es nicht geliefert werden?“
Nur wenn ein gemeinsames Verständnis davon besteht, was die „Done“-Spalte ausdrückt, kann das Team effektiv arbeiten.
Ich kann dich fast hören, wie du denkst: „Wenn mein Team neben der Programmierung auch noch testen und die Dokumentation erstellen muss, dann schaffen wir das nie in einem Sprint.“
Was uns zum nächsten Fehler führt:
Fehler 4: Unfertige Einträge werden am Ende des Sprints aufgeteilt und auf „Done“ gesetzt
Ich wiederhole mich nochmal:
Der Zweck von Scrum ist, eine neue Version des Produkts zu erstellen, die „Done“ ist. Und zwar in weniger als 30 Tagen. Mit der Nutzung von Scrum wollen wir das finanzielle Risiko des Unternehmens auf 30 Tage beschränken.
Die meisten Teams oder Unternehmen, die sich entscheiden, Scrum zu nutzen, erreichen dieses Ziel noch nicht. Deshalb wollen sie ja Scrum nutzen. Die Aufgabe eines Scrum Masters ist, die Verantwortung dafür zu übernehmen, dass das Team diesen Zustand erreicht.
Was meine ich damit?
Betrachten wir ein Beispiel: Am Ende des Sprints sind die Programmierung und der Test zwar abgeschlossen, aber die Aktualisierung des Benutzerhandbuchs noch nicht.
Und jetzt geschieht ein häufiger Fehler:
Der Product-Backlog-Eintrag wird auf „Done“ gesetzt und ein neuer Eintrag für den nächsten Sprint angelegt: „Aktualisierung des Benutzerhandbuchs“. Aus meiner Sicht übernimmst du mit diesem Vorgehen nicht deine Verantwortung als Scrum Master. Du machst es dem Team zu leicht. Du suggerierst dem Team einen Erfolg, der (noch) keiner ist. Wenn du die Verantwortung für Scrum übernimmst, dann bedeutet das, den Mut zu haben, mit dem Team in die Retrospektive des Sprints zu gehen und diese Situation zu thematisieren.
Eine solche Retrospektive gleicht einem aufziehenden Sturm.
Die Mitglieder des Teams werden sagen: „Das ist unmöglich, alle Arbeiten bis zum Ende des Sprints abzuschließen.“ Sie werden sagen: „Ich weiß nicht, wie ich das Handbuch aktualisieren soll“, oder: „Ich bin Informatiker und nicht die Doku-Tante.“
Deine Aufgabe als Scrum Master ist es, für Scrum einzustehen.
Und das ist ein Balanceakt:
Zum einen sind die Sorgen der Entwickler ernst zu nehmen. Zum anderen gilt es, beharrlich nach Verbesserungen zu suchen, die es irgendwann ermöglichen, eine wirklich fertige Version des Produkts in 30 Tagen zu liefern. Sich diesem Sturm zu stellen, erfordert viel Mut.
Es nicht zu tun, ist ein Fehler, der sich am Sprint-Backlog zeigt.