Wenn man ein Projekt nach Scrum durchführen und damit diese Methode zur Softwareentwicklung im Unternehmen einführen will, dann sind es meist die gefühlt hohe Anzahl an Meetings, die dem Management übel aufstoßen. Auf einige Regeln, die ein Meeting von „Overhead“ (also wertlosem Mehraufwand) zu einem gewinnbringenden Aufwand machen, bin ich bereits eingegangen. Aber hat es vor diesem Hintergrund Sinn, neben den täglichen Abstimmungen, den Plannings und Retrospektiven auch noch einen „Backlog Grooming“ Termin einzuführen?
John Sonmez findet in seinem Blogbeitrag „Even Backlogs need Grooming“ einen schönen Vergleich, den ich hier auch aufführen möchte:
Stell dir vor, ein Freund ruft dich (und weitere Freunde) an mit der Bitte, ihm beim Umzug zu helfen. Natürlich sagen die Freunde und du zu und ihr trefft euch zur vereinbarten Zeit pünktlich, um die gepackten Kisten und Möbel in Umzugswagen zu packen und in der neuen Wohnung auszuladen und aufzubauen. Nun kommt ihr alle pünktlich an und seht ein Zimmer, in dem alles kreuz und quer liegt und noch nichts gepackt ist. Das Problem: Nicht alle Freunde können entscheiden, welche Kisten wie gepackt werden sollen, was vielleicht weggeschmissen wird und welche Möbel und Einrichtungsgegenstände als erstes in die neue Wohnung müssen. Also haben viele Helfer wenig zu tun bis alles soweit vorbereitet ist, dass der eigentliche Umzug starten kann.
Das Backlog ist diese Wohnung.
Das Gleiche passiert, wenn man seine Entwickler zusammenruft um die Arbeit eines Sprints zu erledigen. Wenn das Team im Planning für den Sprint anfangen muss, alle Inhalte erst zu sortieren und sich mit Fragen beschäftigen muss, was nun wichtig ist und was nicht, was vielleicht weggeschmissen werden kann und was in welchen Abschnitten gebündelt entwickelt werden muss, dann geht wertvolle Zeit verloren.
Das Backlog Grooming ist etwas anderes, als das Planning. Im Planning geht es um die konkrete Arbeitsplanung eines Sprints. Das Backlog-Grooming organisiert die Arbeit eines Projekts. Es geht in regelmäßigen Abständen um das „Putzen“ bzw. „Pflegen“ der wichtigsten x% des Backlogs mit dem Ziel, einzelne klar geschnürte und verständliche Arbeitspakete zu haben, mit denen man planen und arbeiten kann.
Die Verantwortung für das Backlog hat der Product Owner, es ist dennoch die Arbeitsgrundlage für das gesamte Team und es ist wahrscheinlich, dass der Product Owner gerade beim (vielleicht sogar vom Team abhängigen) schnüren klarer Arbeitspakete die Unterstützung des Teams braucht und auch für die weitere Arbeit in den Sprints ist es hilfreich, wenn das Backlog Grooming vom gesamten Team gemacht wurde.
Schauen wir nochmal auf das Umzugs-Beispiel weiter oben:
Eine unaufgeräumte Wohnung zu einem Umzug ist nicht effizient, weil alle Helfer darauf warten, dass eine Person Entscheidungen trifft und damit nicht gut ausgelastet sind. Das Gleiche passiert, wenn das Entwickler-Team gleichzeitig auf Basis eines nicht gepflegten Backlogs mit dem Planning des Sprints beginnt. Wenn das Backlog nicht aufgeräumt und gut strukturiert ist, dann müssen alle Entwickler im Zweifel mit einer Person (dem Product Owner) reden, sich untereinander mehr abstimmen und können nicht direkt loslegen mit der Planung der eigentlichen Arbeit.
Der Unterschied zwischen dem Backlog Grooming und dem Sprint Planning legen die Meeting-Titel schon nahe, werden aber deutlicher durch die folgenden Fragen:
Im Backlog Grooming sucht man Antworten auf die Fragen:
- Was soll aus fachlicher Sicht in dem Release (oder in dem gesamten Projekt) umgesetzt werden?
- Welche Arbeitspakete schnürt man daraus?
- Welche Daten und Informationen brauchen wir für die jeweiligen Arbeitspakete?
- Was hat welche Priorität für das Release (das Projekt)?
Im Sprint Planning geht es um die Beantwortung der Fragen:
- Wie genau sieht das Arbeitspaket aus und was sind die Fertig-Kriterien?
- Welche Aufgaben (Tasks / Task Breakdown) entstehen daraus abhängig von welchem Lösungsweg konkret?
- Was hat welche Priorität für den Sprint?
Beim Backlog Grooming handelt es sich also nicht um einen der in Scrum fest verankerten Termine, aber um eine sinnvolle Ergänzung. In welchen Iterationen das Backlog Grooming stattfindet und ob der Termin für das gesamte Team oder nur einzelne Vertreter (zum Beispiel ein für das Frontend zuständiger, ein für das Backend zuständiger und ein für das Testen zuständiger Entwickler) sinnvoll ist im Sinne einer guten Kosten-Nutzen-Rechnung, das muss in den jeweiligen Projekten und Teams entschieden werden und kann sich auch immer wieder abhängig von den Rahmenparametern (Team, Projekt, Erfahrung, Laufzeit usw.) ändern.
Empfehlen würde ich, zunächst das Backlog Grooming mindestens einmal pro Release (gegebenenfalls sogar einmal pro Sprint) im gesamten Team zu machen und dann nach Erfahrungen eventuell in einen anderen schmaleren Modus zu wechseln.
Mehr Infos: Jon Sonmez Artikel “Even Backlogs need Grooming”
