In vielen Diskussionen wird dem Product Backlog eine böse Rolle zugeschrieben und es mehr oder weniger verdammt. Damit macht man es sich – aus meiner Sicht – auch etwas zu einfach. Ich glaube nicht an die “Schuld” des Backlogs, sondern vielmehr an den falschen Umgang damit. In diesem Beitrag möchte ich typische Probleme aufführen und bereinigen helfen.

In vielen Diskussionen wird dem Product Backlog eine böse Rolle zugeschrieben und es mehr oder weniger verdammt. Damit macht man es sich – aus meiner Sicht – auch etwas zu einfach. Ich glaube nicht an die “Schuld” des Backlogs, sondern vielmehr an den falschen Umgang damit. In diesem Beitrag möchte ich typische Probleme aufführen und bereinigen helfen.

Backlog != Strategie

In einem Unternehmen oder hinsichtlich eines einzelnen Produktes/Kunden sind Entscheidungen zu treffen und festzulegen. Das kann niemals aufgrund einiger Stories, Wünsche und Ideen eines Backlogs funktionieren. Zu jedem Produkt bestehen (hoffentlich) Visionen und Ziele, die zu erreichen sind. Das Backlog selbst sollte hier nur die Schritte in naher Zukunft dahin, nicht das Rahmenwerk festlegen. Ein Blick über den Tellerrand hinaus ist wichtig.

Das Backlog sollte die Strategie widerspiegeln, nicht umgekehrt.

Platz für Ideen schaffen

Lange Listen haben die Angewohnheit immer länger zu werden. Wird anfangs noch abgearbeitet wird das gerne weniger wenn immer mehr hinzugefügt wird. Das frustiert und man verliert die Lust. Noch schlimmer wird es, wenn eine Grundordnung innerhalb der Liste fehlt.

Eine höhere Chance auf Abarbeitung besteht bei der Verwendung von mehreren Listen für unterschiedliche Anforderungen. Normalerweise gibt es einen Ablauf, einen Prozess, der kann ja abgebildet werden. D.h. ein Eintrag muss dann durch unterschiedliche Listen (Idee, Entwurf, Grooming, …) durch, bis er schlussendlich im Backlog landet. Damit sieht man auch gut, in welchem Status ein Punkt gerade ist, wie weit er schon getrieben wurde. Über Tools wie Atlassian Jira lässt sich dergleichen gut abdecken.

Wird nicht gemacht? Löschen!

Es ist nicht einfach mit Dingen abzuschließen. Oft wurde in Konzepte, Definitionen, Ideen etc. viel Zeit investiert, eventuell auch von einem selbst. Möglicherweise ist einem der Punkt wichtig und will ihn daher noch nicht ganz abhaken, sondern zu einem späteren Zeitpunkt erneut vorbringen. Gerne wird er daher noch im Backlog belassen, selbst wenn es einen gemeinschaftlichen Beschluss gibt, dass die Story nicht durchgeführt wird.

Ballast abwerfen vermindert Frustration und fördert Produktivität.

Eine derartige Story ist aus dem Backlog zu entfernen. Ich empfehle eine generelle Löschung, da daraus gerne eine Liste von nicht ausgeführten Stories entsteht mit der dann auch wieder etwas getan werden muss. Das mausert sich zu einer Last und dies blockiert.

Ist nicht wichtig? Löschen!

Ein Punkt wurde bereits das x-te Mal nach unten geschoben. Immer ist etwas anderes wichtiger. Seit mehreren Sprints schon. Was sagt uns das? Diese Anforderung ist einfach nicht wichtig genug. Besteht die Chance, dass sie auch in den kommenden Sprints geschoben wird, dann ist eine Umsetzung mehr als unrealistisch. Besonders gut zeigt sich das, wenn sich das Team bereits über diese Anforderung lustig macht.

Was nicht wichtig ist, muss weg.

Es ist allen (und vordergründig dem Backlog) geholfen, den Punkt zu entfernen. Sollte das darin enthaltene irgendwann wichtig werden, kommt dies ans Tageslicht und gelangt zur Umsetzung.

Zähneputzen!

Wie man sich jeden Tag die Zähne putzen muss, um spätere Zahn- und Kieferprobleme zu vermeiden, ist es auch mit einem Backlog. Es will regelmäßig gepflegt werden. Die Pflege endet jedoch nicht bei der Priorisierung der Punkte:

  • Bestehende Informationen wollen aktualisiert werden, wenn sich etwas ändert. Nichts ist schlimmer, als in einem der Meetings herauszufinden, dass die Informationen nicht aktuell sind und sofort hektisch begonnen wird, diese auf den aktuellen Stand zu bringen.
  • Verwaltung der Status, Zuführung der Punkte/Stories in die richtigen Gremien (siehe Grooming, Estimation, etc.)
  • Aufarbeitung der Kommunikation, klären von offenen Fragen (z.B. Kommentare etc.)
  • Konsolidierung der vorhandenen Einträge

Bei Änderungen ist darauf zu achten, dass diese nachvollziehbar sind und die Story erneut zumindest in eine Estimation geht – manches Mal kann es auch zurück ins Grooming gehen, je nachdem.

Das Backlog ist kein Archiv, es ist vielmehr die Arbeitsstätte des Product Owners.

Fazit

Das Backlog beschreibt die umzusetzenden Punkte/Stories durch das Entwicklungsteam. Gerne wird es jedoch als Sammelsurium für alle möglichen Anforderungen und Ideen verwendet. Damit verstopft es im Laufe der Zeit wie ein Siphon der nicht gereinigt wird. Eigene Listen für Ideen, Vorschläge und “Work in Progress” helfen hier weiter. So wie der Product Owner das Backlog nicht als Archiv zu sehen hat, ist es legitim, dass das Entwicklungsteam den Product Owner auf Missstände im Product Backlog hinweist.

Wie sind deine Erfahrungen mit Product Backlogs?

Über den Autor

Norbert Eder

Ich bin ein leidenschaftlicher Softwareentwickler und Fotograf. Mein Wissen und meine Gedanken teile ich nicht nur hier im Blog, sondern auch in Fachartikeln und Büchern.