Lieber Nikolaus, wir wünschen uns ein einfaches und leistungsfähiges Tool zur Erfassung und Überarbeitung detaillierter Produktentscheidungen. Und gleichzeitig ein tolles Tool zur Zusammenarbeit von Product Owner und Developers. Lest im Artikel 7 Gefahren in der Arbeit mit dem Backlog und wie wir bei Geek Space 9 es refinen.
Habt ihr auch schon euren Backlog-Wunschzettel geschrieben? Nummer 4 hat uns besonders überrascht! [Bitte nicht bierernst nehmen – wir scherzen immer in unserem Marketing-Mittwoch über clickbaits, deswegen MUSSTE ich einfach. kerstin]
Die Gefahren 1. - 7. für Backlogs erschienen zuerst ausführlicher und in Englischer Sprache im Blog von Roman Pichler. Anschließend zeigen wir euch, wie wir im Refinement als regelmäßigem Team-Termin unser Backlog verbessern.
Wundert euch nicht, “Developers” im folgenden ist keine fehlende Übersetzung, noch handelt es sich alleinig um Softareentwickler. Die Rolle der Developers im Scrum-Team haben wir so direkt aus dem Englischen übernommen und meinen damit alle, die im Sprint den schaffenden und kreativen Teil der Arbeit übernehmen. Lest hier, wie wir “Scrum machen”.
Die 7 Gefahren fürs Backlog
1. Das Product Backlog ist zu groß
Es ist nicht ungewöhnlich, auf Backlogs zu stoßen, die zwischen einigen Hundert und ein paar Tausend Punkten liegen. Ein solches Produkt-Backlog ist jedoch schwer zu erfassen, geschweige denn zu priorisieren und zu aktualisieren. Dies ist vor allem bei jungen Produkten und solchen, die eine größere Veränderung erfahren, z. B. eine Verlängerung des Lebenszyklus, problematisch, da ihre Backlogs dazu neigen, unbeständig zu sein und häufige und manchmal größere Anpassungen erfordern.
Am besten sollte ein Backlog so übersichtlich wie möglich gestaltet sein. Dabei helfen uns gut diese drei Techniken:
- Verwandte Elemente in Themen gruppieren.
- Punkte mit geringer Priorität grob halten.
- Das Backlog aufs Produktziel priorisieren.
Kurz: Das Backlog ist ein lebendiges und sich veränderndes Mittel zur Kommunikation (zwischen den Projektbeteiligten) und kein dickes Requirements-Dokument in Ticket-Form!
2. Das Product Backlog ist zu detailliert
Ein zu detailliertes Product Backlog macht es schwer, den Wald vor lauter Bäumen zu sehen: Es gibt einfach zu viele Informationen. Das wiederum macht es schwierig, Prioritäten zu setzen und das Artefakt zu aktualisieren. Hinzu kommt, dass es wahrscheinlich spekulative und letztlich falsche Punkte enthält, vor allem, wenn der Entwicklungsaufwand von Unsicherheit und Veränderung geprägt ist. Für uns hat es sich als hilfreich erwiesen, mit einem Product Backlog zu beginnen, das absichtlich skizzenhaft und unvollständig ist, vor allem, wenn das Produkt noch jung ist oder eine größere Veränderung erfährt.
Das Backlog kann sich dann “ganz natürlich” auf der Grundlage des Feedbacks von Nutzer:innen, Kund:innen und Stakeholdern weiterentwickeln. Auf diese Weise konnten wir den Aufwand für die Erstellung des Backlogs minimieren und Produktentscheidungen auf empirische Beweise stützen, statt auf pures Bauchgefühl.
Prioritäten sind immer auch ein Anteil Spekulation, auch wenn diese gewissenhaft durchdacht sind. Man sollte also immer bereit sein, diese Annahmen zu überprüfen und anzupassen.
3. Das Product Backlog ist zu wenig detailliert
Auch wenn ein Product Backlog nicht detaillierter als nötig sein sollte, müssen trotzdem die Elemente mit hoher Priorität ausreichend detailliert sein. Zumindest uns hilft das.
Dazu müssen die Hoch-Priorität-Items folgenden drei Kriterien erfüllen:
- Beschreibung hinreichend klar und von den Developers verstanden.
- Können in einem Sprint gemäß der Definition of Done abgeschlossen werden.
- Können getestet werden.
4. Das Produkt-Backlog ist eine Wunschliste
Oft ähneln Produkt-Backlogs einer Wunschliste, einem Katalog, der alles enthält, was jemals für das Produkt gebraucht werden könnten. Das Problem mit einem solchen Backlog ist nicht nur, dass es normalerweise zu groß ist. Es führt auch zu einer “Funktionssuppe”, einem Produkt, das einer losen Ansammlung von nicht zusammenhängenden Funktionen ähnelt. Dies führt zu einem schwachen Wertversprechen und einer schlechten Benutzererfahrung, was kaum ein Kennzeichen für ein großartiges Produkt ist.
Aber wenn diese Backlogs so schlecht sind, warum gibt es sie dann? Dafür gibt es zwei Hauptgründe: Erstens ein Mangel an strategischer Ausrichtung und Fokussierung und zweitens ein Mangel an Befähigung.
Um zu verhindern, dass das Product Backlog zu einer Wunschliste wird, helfen uns diese beiden Dinge:
- Produktziel und Vision klären, und das Produkt daran ausrichten.
- Habe den Mut, “Nein!” zu sagen. Ideen und Anfragen, die nicht zur Produkt-Vision passen, werden abgelehnt.
5. Das Product Backlog ist nicht effektiv priorisiert
Wenn alles eine hohe Priorität hat, ist alles gleich wichtig. Das bedeutet, dass nichts Priorität hat. Aber ohne klare Prioritäten fehlt den Developers die Orientierung.
Wenn es euch schwer fällt, Prioritäten fürs Product Backlog zu setzen, können wir diese beiden empfehlen – uns hat es geholfen:
- Sicherstellen, dass alle Backlog Items der Produkt-Vision dienen.
- Eine kleine Anzahl an Faktoren festlegen, die die Priorisierung erleichtern, wie z.B. Risiko, Kosten-Nutzen-Verhältnis, Abhängigkeiten.
Es ist z.B. eine Möglichkeit, das so umzusetzen: Backlog-Items zuerst nach Risiko bewerten. Items mit hohem Risiko bezüglich Benutzer:innen, Technologie, Business werden nach oben priorisiert. Dieser Ansatz beschleunigt den Lernprozess und verhindert, sehr spät zu scheitern, wenn ein Kurswechsel teurer ist.
6. Das Product Backlog wird nicht mit allen Stakeholdern geteilt
Es ist nicht unüblich, dass die Developers nicht “tief” in die Arbeiten am Backlog selbst eingebunden sind. Das Verfeinern, Priorisieren und Aktualisieren des Backlogs sollte jedoch in Teamarbeit erfolgen.
Die gemeinsame Arbeit am Product Backlog und die gemeinsame Erstellung seiner Elemente bietet die folgenden zwei Vorteile:
- Das kollektive Wissen und die Kreativität der Developers führt zu besseren Backlog-Items. Und gleichzeitig kann der Product Owner Wissen über Nutzer:innen und deren Bedürfnisse weitergeben.
- Wertschätzung und Respekt fürs gesamte Scrum-Team indem gemeinsam Entscheidungen getroffen und Lösungen gefunden werden. Das stärkt das Individuum und erhöht die Motivation, am Produkt mitzuwirken, statt nur Anforderungen “vorgesetzt” zu bekommen.
7. Dem Product Backlog fehlt die strategische Ausrichtung
Ein häufiger Fehler im Product Backlog und eine der Hauptursachen für mehrere der oben genannten Fehler ist die fehlende strategische Ausrichtung: Das Backlog ist nicht systematisch mit der Produktvision verbunden. Ohne eine strategische Ausrichtung und ein klares Produktziel kann das Backlog jedoch leicht zu groß werden, schwer zu priorisieren sein und sich in eine Wunschliste verwandeln. Anhand der Produkt-Vision wird festgelegt, welche Elemente in das Backlog aufgenommen werden sollen: nur solche, die zur Erreichung des Ziels beitragen.
Geek Space 9 Backlog-Refinement
(= regelmäßiger interner Termin fürs Scrum-Team)
Im Scrum-Cycle bietet das Backlog Refinement eine optimale Gelegenheit, dieses auf die sieben Gefahren zu prüfen und diese gegebenenfalls zu beseitigen.
Nur ‘fertige’ User Stories (vgl. DOR: Definition of Ready und Ticket-ready-check) sollten im Sprint Planning besprochen werden. Daher werden im Backlog Refinement UserStories/Epics für das nächste Planning gemeinsam vorbereitet und konkretisiert, wenn sie vom Product Owner (PO) allein nicht fertiggestellt oder konzipiert werden können (aus vielen möglichen Gründen: Zeitmangel, Hintergrundwissen, etc.). Mehr zu den Refinement Basics lest ihr auf unserer Scrum-Seite (zu der auch Planning und DOR oben verlinken).
Wie machen wir das? Geek Space 9 Realität
Für uns hat sich in der Praxis eine Mischform bewährt:
- 1h-Check in der Woche vor der Planung: Immer eine Stunde einplanen, denn in genau einer Stunde kann man in der Regel genau so viele Stories zusammen anschauen, wie dann im Sprint landen … so unsere Erfahrung. (Zusammensetzung: auf jeden Fall mit allen Developers, optional mit Scrum Master und/oder PO).
- Refinement eine Woche nach Planning: in Projekten oder Projektphasen, wenn viel Konzeptarbeit zu leisten ist (Zusammensetzung: gesamtes Scrum-Team), hat sich ein regelmäßiges Refinement als nützlich erwiesen das immer 1 Woche versetzt zum Planning stattfindet.
- Refinement als zusätzliche Timebox: wenn klar wird, dass ein spezielles Thema oder eine Funktion ein großer Brocken ist oder knifflig sein könnte, vereinbaren all jene Teammitglieder eine extra Timebox, die am meisten zu diesem speziellen Thema beitragen können (Zusammensetzung: je nach Thema)
Warum das alles?
Damit eine User Story ihre Aufgabe in einem Sprint gut erfüllen kann, muss sie
- von den Developers verstanden werden (“verstanden” klingt jetzt so einfach, ist aber in Wirklichkeit ein Maß für die Qualität der Stories) und
- möglichst wenig Fallstricke und Ungereimtheiten enthalten, damit es während des Sprints nicht zu Missverständnissen und Überraschungen kommt.
Das lässt sich nie ganz vermeiden. Aber wenn ihr im Refinement und Planning mehrere Gelegenheiten schafft, um euch ein gemeinsames Bild zu machen, seid ihr auf dem richtigen Weg. Je mehr ihr in den Refinements gemeinsam an Stories und Konzepten gearbeitet habt, desto einfacher ist es, sie zu “verstehen”…und damit auch euch gegenseitig ;)
Es geht einfach darum, einen Modus der Zusammenarbeit zu finden. Und das Refinement ist deshalb so gut, weil die/der PO Gedanken nicht nur in User Stories niederschreibt und Developers dann bei der Planung damit überrascht. Sondern: Oft ist es eine Zusammenarbeit zwischen dem inhaltlichen Konzept (das primär vom PO kommt) und dem technischen Konzept (das von den Developers kommt). Das schafft Raum in der Verfeinerung. Außerdem fällt es leichter zu erkennen, wenn etwas fehlt oder noch nicht stimmt, wenn man vor dem Planning gemeinsam an den Stories arbeitet.
Dieser (und mehr) Scrum-Content erschien zuerst und ausführlicher auf https://gs-9.com/methoden-und-prozesse-scrum/.
Lust bekommen, mit uns zu scrummen?
Komm ins Team, wir freuen uns immer über neue Kolleg:innen. Das sind unsere Jobs. Aktuell suchen wir Product People.
