Was schaust du dir als Erstes an, wenn du neu in einem Scrum-Team bist?
Ich lasse mir das Backlog zeigen. Die Länge verrät meist schon viel über das Produkt und das Team und lässt Rückschlüsse auf die Arbeitsweise im gesamten Unternehmen zu. Allerdings toppt das nicht die Rückmeldung einer Teilnehmerin im „Professional Scrum Product Backlog Owner“-Training im September. Sie meinte tatsächlich, dass sie aktuell über 730 Einträge im Backlog habe. Nochmal in Worten: siebenhundertdreißig.
Wahnsinn.
Natürlich gibt es auch immer Gründe dafür.
Die Gründe für lange Product-Backlogs
Hier drei, die mir häufig begegnen:
- Was im Product-Backlog einmal niedergeschrieben ist, kann nicht mehr verloren gehen.
- Ein großes Product-Backlog zeigt, dass die Entwicklung des Produkts gut vorbereitet wurde.
- Mehr Backlog-Einträge bedeuten mehr Optionen, also auch mehr Wahlmöglichkeiten für Kunden.
Unterm Strich:
Ein langes Product-Backlog vermittelt ein Gefühl von Kontrolle.
Tatsächlich ist meist nichts ferner von der Wahrheit. Es ist doch eher Ausdruck eines Depots für Risiken, Illusionen und verschleppte Entscheidungen. Allerdings – und jetzt möchte ich ganz ehrlich mit dir sein – werden Scrum-Guru-Ratschläge das Problem nicht lösen.
Ratschläge wie:
- Der Product-Owner muss lernen, nein zu sagen.
- Das Product-Backlog darf keine To-do-Liste sein.
- Hat das Backlog mehr als 30 Einträge? Dann lösche einfach jeden weiteren.
Klingt erst einmal einleuchtend.
Zeigt aber, dass der Guru wohl schon länger nicht mehr mit Teams gearbeitet hat. Sagst du leichtfertig nein zu deinen Stakeholdern, wenn sie auch über dein Gehalt entscheiden? Wenn das Product-Backlog keine To-dos für das Team enthalten darf, wohin dann mit der Aufgabe, die ganzen technischen Schulden abzubauen? Und sollten Einträge gelöscht werden, wenn sie noch für Dokumentationszwecke genutzt werden? Und noch schlimmer: Damit doktert der Guru doch nur an Symptomen herum.
Die Ursache ist meist eine ganz andere.
Und einfach mal alle Einträge zu löschen, löscht doch nicht auf magische Weise die Ursache des Problems gleich mit.
Hier drei Ursachen, die mir regelmäßig begegnen:
Ursache #1: Keine regelmäßigen Releases
Zugegeben, diese Ursache klingt wie ein Relikt aus einer längst vergangenen Zeit.
Allerdings: Nur weil Amazon angeblich alle 11 Sekunden neue Software produktiv setzt, gilt das nicht für jedes Unternehmen. Wobei ich mich schon manchmal ernsthaft frage: Mit dem Einsatz von KI muss das doch endlich für jedes Team klappen.
In der Realität gilt leider noch das Gegenteil.
Über zehn Jahre in der Produktentwicklung führen mir das immer wieder vor Augen. Und mittlerweile glaube ich, es liegt nicht mehr daran, dass Teams es technisch nicht können, sondern daran, dass sie manchmal auch Angst davor haben. „Move fast, break things“ bedeutet halt auch, den Mut aufzubringen, Kunden mal zu verärgern.
Der Scrum Guide ist hier auch zu zaghaft.
„Ein Inkrement könnte jedoch auch schon vor Ende des Sprints an die Stakeholder geliefert werden.“
Dieser Satz ist mir zu zaghaft. Wieso nicht „könnte jedoch“ durch „sollte“ ersetzen?
Meine Erfahrung zeigt mir immer wieder: Wenn der Kunde das Produkt zum ersten Mal in den Händen hält, dann ändert sich das Product-Backlog grundlegend.
Was uns zur nächsten Ursache bringt. Aber bevor wir uns dieser widmen:
Leidet dein Team unter einem zu langen Product-Backlog? Dann analysiere doch die Release-Häufigkeit deines Teams.
Vielleicht findest du darin die Ursache.
Nun zur nächsten Ursache:
Ursache #2: Keine Sprint-Reviews
Lass uns zuerst mit einem Irrtum aufräumen.
Das Sprint-Review ist kein Meeting, sondern ein Event. Für viele lässt sich auf den ersten Blick kein Unterschied erkennen. Meeting oder Event – ist doch das Gleiche. Nicht ganz. Woran denkst du, wenn du das Wort „Meeting“ hörst? Ich denke an: „Wir müssen mal reden.“ Also eine Besprechung. Passiert meist ad hoc, die Zeit muss nicht eingehalten werden, als Ergebnis ist es okay, wenn wir uns für morgen noch mal verabreden.
Das hat nichts mit den Events in Scrum zu tun.
Deshalb heißen sie nicht „Scrum Meetings“. Events in Scrum sind eher mit einem Herzschlag zu vergleichen. Ein regelmäßiger Rhythmus, der den Organismus arbeitsfähig hält. In Scrum helfen sie, die Produktentwicklung langfristig am Leben zu erhalten, indem sie regelmäßig den Ist-Zustand überprüfen und Kurskorrekturen ermöglichen.
Im Fall des Sprint-Reviews zeigt sich diese Kurskorrektur in der Aktualisierung des Product-Backlogs.
Liefern Teams regelmäßig, erheben Feedback und diskutieren dieses Feedback im Sprint-Review, dann ist es fast unausweichlich, dass sich das Product-Backlog verändern wird. Denn erst wenn die Nutzer das Produkt wirklich nutzen, erfahren wir, welche Funktionen gut ankommen und wirklich genutzt werden.
„Bei AWS stammen rund 90 % der entwickelten Funktionen direkt aus den Bedürfnissen unserer Kunden. Die restlichen 10 % entstehen dadurch, dass wir so nah an unseren Kunden sind, dass wir für sie entwickeln können, wenn sie diese Bedürfnisse nicht artikulieren können oder wollen.“
Das führt unausweichlich dazu, dass neue Erkenntnisse entstehen – und damit neue Ideen ins Backlog wandern, an die vorher niemand gedacht hat. Gleichzeitig bedeutet es aber auch, dass viele zuvor detailliert geplante Anforderungen plötzlich irrelevant werden. Und somit war die Zeit für aufwendige Anforderungsanalysen, Refinement und Backlog-Management rückblickend nur ein Kostenpunkt.
Deshalb noch einmal die Frage:
Leidet dein Team unter einem zu langen Product-Backlog? Dann frage dich unbedingt: Erhalten wir regelmäßig Feedback von unseren Nutzern, Kunden und Stakeholdern aus dem Unternehmen? Werten wir Nutzungsdaten und Absatzzahlen aus? Wie monitoren wir den Erfolg des Produkts?
Vergiss dabei nicht:
Das Sprint-Review ist nicht irgendein Meeting, sondern stellt den Herzschlag von Scrum dar. Es hilft, das Produkt weiterzuentwickeln und die Prioritäten im Backlog neu zu ordnen. Und um Zeitverschwendung möglichst gering zu halten, sollte das Backlog auch möglichst kurz sein.
Was uns zur letzten Ursache für heute bringt:
Ursache #3: Kein „wirklicher“ Product-Owner
Was bedeutet es, den Erfolg eines Produkts wirklich zu verantworten?
Der Scrum Guide beschreibt dies so:
„Der Product-Owner ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum-Teams ergibt. Wie dies geschieht, kann je nach Organisation, Scrum-Team und Individuum sehr unterschiedlich sein.“
Wichtig ist der Teil „Maximierung des Wertes des Produkts“. Der Product-Owner verantwortet die Maximierung des Wertes. Was bedeutet Maximierung? Was muss erfüllt sein, damit der Wert des Produkts maximiert werden kann?
Wertmaximierung erfordert nur zwei Entscheidungen:
- Was ist Bestandteil des Product-Backlogs?
- Wann liefern wir das Inkrement?
Ein überlanges Product-Backlog ist häufig ein Symptom dafür, dass Product-Owner eine der beiden Entscheidungen nicht frei treffen können.
Und anstatt Product-Ownern als Ausweg anzubieten, sie sollen doch lernen nein zu sagen, sollten wir versuchen, die Situation, in der sie sich befinden, besser zu verstehen.
Sehen wir uns diese beiden Entscheidungen auf einem Spektrum an:
Von „kein Mandat“ zu „CEO des Produkts“ und von „jährliche Releases“ zu „kontinuierliche Releases“, dann ergibt sich daraus ein einfaches Diagnose-Werkzeug.
Es besteht aus diesen vier Szenarien:
Szenario 1: kein Mandat und kontinuierliche Releases
Der Product-Owner agiert wie ein Release-Koordinator.
In diesem Bereich können wir häufig beobachten:
- Das Backlog wächst. Es werden wenige Einträge gelöscht.
- Viele Einträge werden an den Product-Owner „durchgereicht“.
- Das Sprint-Review gleicht einer Demo oder einem Abnahme-Meeting.
- Der Product-Owner schreibt, klärt Details der Einträge im Product-Backlog und organisiert Übergaben und Abnahmen.
Szenario 2: kein Mandat und jährliche Releases
Der Product-Owner agiert wie ein Projektleiter in einem Wasserfall-Projekt.
In diesem Bereich können wir häufig beobachten:
- Das Backlog gleicht einer (technischen) To-do-Liste.
- Der Product-Owner stellt sicher, dass die Entwickler ausgelastet sind.
- Planung dominiert: Die Roadmap gleicht Projektplänen oder Lieferverträgen.
- Im Sprint-Review wird die Arbeit für das große Release akzeptiert oder abgelehnt.
Szenario 3: CEO des Produkts und kontinuierliche Releases
Der Product-Owner nutzt Releases als Lernschleifen, um seine Entscheidungen zu überprüfen.
In diesem Bereich können wir häufig beobachten:
- Das Product-Backlog ist kurz und klar geordnet; Einträge werden auch aktiv entfernt.
- Der Product-Owner priorisiert das Product-Backlog nach Risiken.
- Im Sprint-Review werden Veränderungen am Markt, am Budget und am Backlog besprochen und Entscheidungen getroffen, welche Opportunität als Nächstes verfolgt werden sollte.
- Das Team erhält regelmäßige Kundensignale (durch Tests und Nutzerdaten).
Szenario 4: CEO des Produkts und jährliche Releases
Der Product-Owner bereitet den großen Go-live vor.
In diesem Bereich können wir häufig beobachten:
- Das Product-Backlog gleicht einem Projektplan.
- Releases werden langfristig geplant und vorbereitet.
- Das Sprint-Review dient der Überprüfung und Anpassung von Budget und Timeline.
- Die Feedback-Lücken zwischen den Releases werden mit Kundeninterviews und Nutzertests überbrückt.
Jetzt kennst du die vier Szenarien, in denen Product-Owner typischerweise agieren.
Und abermals eine Frage, die du dir stellen solltest: Ist das Product-Backlog sehr lang? Dann überlege, in welchem dieser Szenarien der Product-Owner dieses Produkts agiert.
Die Chance steht sehr gut, dass er sich nicht in Szenario 3 befindet. Nutze nun diese Erkenntnis, um ihn gezielt dabei zu unterstützen, mehr Entscheidungsverantwortung zu erlangen – ohne ihn vorschnell zu verurteilen, dass er bloß nicht nein sagen kann.
Zum Abschluss:
Nochmal die 3 Fragen in der Übersicht:
- Frage #1 – Liefern & Lernen: Wann haben wir zuletzt produktiv ausgeliefert und was haben wir konkret daraus gelernt? Was braucht es, um die Release-Frequenz zu erhöhen?
- Frage #2 – Herzschlag prüfen: Wie stellen wir sicher, dass das Sprint-Review echte Nutzungssignale (Daten, Feedback, Zahlen) ins Backlog bringt, und welche Einträge entfernen wir dadurch heute?
- Frage #3 – Mandat klären: Hat unser Product-Owner das Mandat, über Inhalt des Backlogs und Zeitpunkt von Releases zu entscheiden? Wenn nicht: Wer hat es und was ist der nächste kleine Schritt, um dieses Mandat zu erweitern?