Das Backlog ist ein wichtiges Artefakt von Scrum. Es ist als Product- und Sprint-Backlog Bestandteil des agilen Prozesses. Es beschreibt den aktuellen Zustand der Planung für das Produkt bzw. den Sprint für das nächste Produktinkrement. In Rahmen meiner Zertifizierung zum Product-Owner hat der Kursleiter Roman Pichler den Begriff “Backlog-Management” geprägt. Er subsummiert darunter die bekannten Begriffe wie “Grooming” und “Refinement”. Seiner Meinung nach hat vor allem der Begriff “Grooming” störende Konotationen. Der Begriff “Management” hingegen beinhaltet ganz klar alle Arten von Veränderungen, die wir in einem Backlog machen.

12 Wie pflegen wir das Backlog

Management für das Backlog

Ein ganz wichtiges Ziel des Managements für ein Backlog ist es, den Umfang der Liste zu kontrollieren. Auch die Qualität der Einträge muss “gemanagt” werden. Der Product-Owner ist dafür verantwortlich. Er ist der Manager des Backlog.

Roman Pichler hat im Kurs vier Szenarien des Backlog-Managements identifiziert. Nach meinem Verständnis unterscheiden sich die Szenarien in der Art und Weise, wie der Product-Owner das Feedback der Stakeholder verarbeitet.

12 Wie pflegen wir das Backlog - Bild1

Der Product-Owner verarbeitet das Feedback aus dem Review-Meeting sofort. Er benötigt keine Hilfe vom Team, um die Veränderungen im Backlog schnell und unabhängig vorzunehmen. Das Team wird im nächsten Planning-Meeting die Veränderungen im Backlog berücksichtigen.

Das Szenario setzt voraus, dass der Product-Owner in der Lage ist, das Feedback allein und in sehr kurzer Zeit zu verarbeiten, quasi in “Echtzeit”. Das halte ich für sehr ambitioniert. Ich kann mir gut vorstellen, dass so ein Vorgehen bei einem reifen Produkt erfolgreich ist. Aber in diesem Fall ist der Einsatz von Scrum nicht mehr optimal.

12 Wie pflegen wir das Backlog - Bild2

Der Product-Owner sammelt das Feedback aus dem Review-Meeting ein. Die notwendigen Veränderungen sind umfangreicher. Daher bespricht er sie in einem zusätzlichen Refinement-Meeting kurz vor dem nächsten Planning-Meeting. Dadurch ist das Team im gleich danach folgenden Planning-Meeting bereits über die Veränderungen im Backlog informiert.

Das Szenario ist eine Variante von Szenario #1. Durch das zusätzliche Meeting kann das Feedback konzentriert und zielgerichtet verarbeitet werden. Der Product-Owner kann diese Aufgabe zusammen mit dem Team (oder einem Teil davon) erledigen.

12 Wie pflegen wir das Backlog - Bild3

Der Product-Owner erhält neben dem Feedback aus dem Review-Meeting weiteres Feedback durch Datenanalysen. Die Ergebnisse sind aber nicht sofort verfügbar. Darum muss der Product-Owner mit dem Backlog-Management warten. Damit ist es unmöglich, das Backlog vor dem nächsten Planning-Meeting anzupassen. Der nächste Sprint startet mit einem Backlog, in dem das Feedback noch nicht vollständig berücksichtigt wurde.

Das Szenario birgt ein gewisses Risiko, dass im nächsten Sprint ein Produktinkrement entsteht, dass nicht vollständig auf direktem Weg zum “idealen” Produkt liegt. Scrum tritt an, um diesem speziellen Risiko zu begegnen.

12 Wie pflegen wir das Backlog - Bild4

Der Product-Owner bekommt laufend Feedback zum Produkt und damit auch zum Backlog. Natürlich ist ein Review-Meeting ein wichtiges Werkzeug, um zielgerichtetes Feedback zu bekommen. Aber es gibt weitere Quellen für Feedback:

  • Ergebnisse aus Datenanalysen.
  • Erkenntnisse aus der Entwicklung oder dem Test während des Sprints.
  • Veränderungen im Umfeld des Projektes.
  • Veränderungen im Markt, für den das Produkt entwickelt wird.

In diesem Szenario spielt es keine Rolle, wann der Product-Owner Feedback zum Backlog bekommt. Darum muss der Product-Owner laufend das Backlog entsprechend den vielfältigen Informationen verändern.

Werkzeuge für das Backlog

Der Einsatz eines Werkzeuges wie JIRA ist weit verbreitet. So ein Werkzeug soll den Prozess optimal unterstützen. Das Product- und Sprint-Backlog wird durch JIRA für alle sichtbar und verfügbar, am Arbeitsplatz, auch verteilt, oder unterwegs am Tablet oder Smartphone. JIRA unterstützt uns vorrangig in unserem agilen Prozess.

Auch die Verwendung einer “analogen” Form eines Backlogs ist möglich. Ein für alle im Team sichtbares Sprint-Backlog mit Karten an einer Wand im Büro erfüllt sehr gut seinen Zweck. Voraussetzung ist aber, dass das Team zusammen an einem Ort arbeitet.

Betrachten wir speziell das Szenario mit kontinuierlichem Feedback, dann bekommt der Product-Owner mit einem Wiki ein mächtiges Werkzeug in die Hand. Er kann damit die Inhalte seines Backlog effizienter vorbereiten. Er kann mit den kontinuierlichen Veränderungen besser umgehen. Die Methode CARDS+ gibt dem Wiki eine Struktur, die sehr gut zu einem Backlog passt. Der Product-Owner bekommt zielgerichtetes Feedback. In einem Review-Meeting kann er sichtbar für die Stakeholder und andere Teilnehmer das Feedback als Kommentar im Wiki erfassen. Missverständnisse beim Feedback werden dadurch weitestgehend ausgeschlossen. Das Projekt profitiert vom Wiki ebenfalls, hat doch jeder Projektmitarbeiter Zugriff auf das Produktwissen. Und sie können jederzeit durch Kommentare auch ohne spezielles Meeting ihr Feedback abgeben.

Ein Werkzeug ist nur Mittel zum Zweck. Es muss zum Team passen, zu den Fähigkeiten und Wünschen der Personen.

A fool with a tool is still a fool.

Der Einsatz eines Werkzeuges sollte daher regelmäßig in der Retrospektive bewertet werden. Das gilt auch für das Wiki. Fehlt die Motivation für die Pflege der Inhalte, dann macht ein Wiki keinen Sinn. Keine Dokumentation ist in so einem Fall besser als eine schlechte Dokumentation.

Management für Produktwissen

Das Product-Backlog ist ohne Frage wichtig. In einem gut gepflegten Backlog steckt viel Arbeit. Es kann aber nicht zur gleichen Zeit flexibel hinsichtlich Veränderung und stabil als Quelle für Produktwissen sein. Es ist daher nicht sinnvoll, ein Backlog als Sicherung von Wissen zu betrachten.

Das Product-Backlog bei Scrum ist keine vollständige Liste der Anforderungen an das Produkt, sondern der gegenwärtige Kenntnisstand, der sich durch das Feedback oder wechselnde Rahmenbedingungen ständig ändert.

Die Methode CARDS+ bietet ein einfaches Rezept, Produktwissen zu sichern. Wie ein Koch beim Backen eines Kuchens Eiweiß vom Eigelb trennt, separiert ein Product-Owner die Geschichte von den Akzeptanzkriterien einer Story.

Mit der Methode CARDS+ trennen wir konsequent Produktwissen vom Product-Backlog.

Gerade in einem agilen Umfeld wird sehr viel Wissen nur durch Kommunikation vermittelt. Dieses wertvolle Wissen existiert in Köpfen. Es geht sehr leicht verloren.

Sicherung von Produktwissen

Ein Wiki ist ausgezeichnet geeignet zur Sicherung von Wissen. Wir schätzen den Wert von Wikipedia als Quelle universellen Wissens. Gerne nutzen wir Stichworte für Querverbindungen und geben Feedback mit Kommentaren. Was liegt daher näher als ein Wiki für die Sicherung von Produktwissen zu verwenden. Durch die Methode CARDS+ geben wir eine feste, nachvollziehbare Struktur für die Systembeschreibung und die Architekturdefinition vor. Wir schreiben von Anfang an ein Glossar. Vorgaben zu Form und Inhalt versetzen uns in die Lage, die Seiten im Wiki formal und inhaltlich zu prüfen. Was in Wikipedia in großen Stil funktioniert, klappt so auch in einem Projekt. Stakeholder, der Product-Owner und das cross-funktionale Team sind gleichzeitig Leser und Autoren im Wiki.

Häufig stellt ein Auftraggeber die Frage nach dem zusätzlichen Aufwand für die Pflege des Wiki. In meiner Antwort unterscheide ich zwischen Erfassung und Pflege von Produktwissen.

Erfassung von Produktwissen

Bei der Erfassung von Produktwissen im Wiki sehe ich keine Mehrarbeit für die Projektmitarbeiter. Wissen muss immer auf irgendeine Art vermittelt werden. Ob Gespräche oder Workshops mit Protokoll, persönliche Unterlagen, Konzeptionen, Spezifikationen, immer gibt es jemanden, der die Information hat. Wir sind durch die Methode CARDS+ in der Lage, einmal erarbeitetes Produktwissen sofort und zielsicher im Wiki zu erfassen:

  • Topics bereits beim Projektstart,
  • Epics in der Anforderungsanalyse,
  • Cases während des Backlog-Management und
  • Layouts aus dem UX-Design.

Die Übernahme der “rohen” Informationen in das Wiki geschieht jedoch geordnet, mit hoher Qualität. Bei diesem Vorgang ist besonders wichtig, die Essenz, das Wesentliche der Information zu erkennen. Nur dieses kompakte Wissen sichern wir im Wiki. Und das Feedback der Kollegen gibt uns die notwendige Versicherung, alle relevanten Informationen erfasst zu haben. Im Zweifel gilt hier der Spruch: Weniger ist mehr.

Pflege von Produktwissen

Spannend wird es, wenn es um die Pflege von Produktwissen geht. Hier müssen wir investieren, um die Qualität im Wiki zu halten. Wir müssen uns schon bei der Erfassung Gedanken machen, wie wir die Inhalte pflegen. Wir müssen uns auf das Wesentliche beschränken, um nicht in einer Unmenge von Detailwissen zu ersticken. Wir müssen bei der Erfassung Wiederholungen vermeiden, um später bei der Pflege keine widersprüchliche Inhalte zu bekommen. Mit der Methode CARDS+ empfehlen wir verschiedene Prinzipien und Praktiken der Programmierer, angewendet auf das Schreiben von Texten.

Eine Korrektur im Wiki ist immer dann notwendig, wenn sich ein Sachverhalt ändert oder eine neue Erkenntnis entsteht. Ein gutes Indiz für den Bedarf an einer Änderung ist die Menge an Kommentaren. Je kontroverser die Fragen und Hinweise sind, desto größer ist der Handlungsbedarf.

Moderierte Kommentare im Wiki sind eine hilfreiche Metrik für die Qualität der Produktdokumentation.

Unsere Aufgabe ist nicht nur die Pflege von Inhalten in den Seiten des Wiki, sondern auch die Moderation der Kommentare. Im Sinne der Nachhaltigkeit entfernen wir Kommentare, die bereits zur Korrektur des Inhaltes verwendet wurden. Auch nicht mehr relevante oder sachlich nicht korrekte Kommentare entfernen wir. Nur durch aktives Management der Kommentare können wir sie als Indikator für die Qualität der Dokumentation heranziehen.

Wert von Produktwissen

Am Ende eines jeden Sprints haben wir eine fertige Produktdokumentation passend zum Produkt. Dieses immer vorhandene Sprint-Ziel erreichen wir nur durch gemeinsame Anstrengungen von Product-Owner und cross-funktionalem Team. Der Einsatz sind Disziplin, Reviews und Feedback, der Gewinn ist hohe Qualität. Die Produktdokumentation ist ein wertvolles Gut. Die “Geschichten” im Wiki, strukturiert in Epics, Cases und Layouts, gruppiert in Topics, können ideal mit einem Product-Backlog aus Stories kombiniert werden. Mit der Trennung von Wiki und Backlog sind wir komplett frei in der Wahl der Werkzeuge für die Durchführung der Sprints. Das Team kann sich für JIRA entscheiden, es kann aber ohne Abstriche mit analogen Karten und einer Pin-Wand arbeiten.

Fazit

Am Ende eines erfolgreichen Releases kann der Product-Owner das Product-Backlog verlustfrei aufräumen. Verlustfrei, weil das Produktwissen vollständig im Wiki gesichert wurde. Das Wiki steht außerdem für das gesamte Projekt für Recherchen zur Verfügung, wie wir es von wikipedia kennen. Ein nicht zu unterschätzender Vorteil.

Die Erstellung und Pflege einer Produktdokumentation wird gerade zu Beginn eines Projektes häufig in Frage gestellt. Der Verzicht auf diese Dokumentation sollte nicht voreilig getroffen werden. Die Produktdokumentation später, quasi als “Nachdokumentation”, zu erstellen, ist meiner Ansicht immer zum Scheitern verurteilt. Die Gründe sind vielfältig: Wichtige Stakeholder oder andere Spezialisten sind nicht mehr greifbar, die spannenden Details sind nur Entwicklern bekannt. Die Produktdokumentation wird zum Alibi.