Clean Up Backlog

Backlog Grooming – sinnvoll oder Overhead?

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: Angela Druckman: „How to Hold an Effective Backlog Grooming Session„, Jon Sonmez Artikel “Even Backlogs need Grooming

2 Comments

Leave a Comment
  1. Warum reicht es nicht das Backlog Grooming allein mit dem Scrum Master abzuhalten. Ich würde das eher als grobe Vorbereitung auf die große Sprint Planung sehen. In dem Backlog Grooming kann der PO seine geplante Prio gegenchecken lassen bevor es in die große Runde geht. Unsere Agentur macht zwar kein Scrum habe, haber aber bei einer aktuellen Projekteumsetzung einige Elemente aus Scrum ausprobiert. Dazu habe ich vor der Sprint Planung eine Vorbesprechung mit dem TV (Technisch Verantwortlicher auf dem Projekt) gehabt. Das hat geholfen einige Denkfehler in der Priorisierung die der PM technisch nicht im Detail bewerten kann, vorab noch anzupassen.

    1. Wie so oft ist das abhängig von der konkreten Situation (Thema, Team und so weiter). Verantwortlich für den fachlichen Teil des Backlogs ist der Product Owner und ich kann mir vorstellen, dass es schwierig wird, die geplante Prio gegenchecken zu lassen, wenn der PO hierbei nicht für Fragen zur Verfügung steht.

      Im optimalen Fall braucht man das Grooming vielleicht gar nicht, weil alle benötigten Infos so klar sind, dass sich das Team im Sprint-Planning einfach losplanen kann. Meiner Erfahrung nach fehlt aber meistens fachliche Informationen für die Schätzung. Ein Grooming vorab deckt das auf und gibt dem PO die Möglichkeit, offene Fragen bis zum Planning zu klären damit die Planung dann überhaupt gut möglich ist. Meiner Erfahrung nach ist es unbedingt sinnvoll, den PO im Grooming dabei zu haben, weil sich so einige Fragen auch direkt und schnell klären lassen.

Schreibe deinen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Achtung: Ich erkläre mich damit einverstanden, dass alle eingegebenen Daten und meine IP-Adresse nur zum Zweck der Spamvermeidung durch das Programm Akismet in den USA überprüft und gespeichert werden.
Weitere Informationen zu Akismet und Widerrufsmöglichkeiten.