Product Backlog
Ein gutes Product Backlog hilft dabei besser bessere Produkte zu entwickeln. Erfahre auf dieser Seite, worauf es dazu bei einem guten Product Backlog ankommt.
Infos zum
Product Backlog
Was ist das Product Backlog?
Ein Product Backlog ist eine Liste von Anforderungen, Funktionalitäten bzw. Verbesserungsvorschlägen. In ihm organisiert man aktuell bekannten Themen für die Produktentwicklung.
Ein Backlog ist priorisiert. So forciert ein Product Backlog eine schnelle fokussierte Entwicklung von minimalen Ergebnissen. Aus diesen Lernen wir stetig dazu. In diesem Sinne ist ein Product Backlog niemals vollständig oder fertig. Es entwickelt sich stetig weiter.
So gibt uns ein aktuelles Backlog eine gemeinsame Orientierung von dem, was wir aktuell als nötig sehen, um unser Produktziel zu erreichen.
Was du übers Backlog wissen solltest!
Mehrwert eines Product Backlogs
Richtig genutzt, ist ein Product Backlog der Schlüssel zu einer effektiven agilen Produktentwicklung.
Schafft gemeinsames Verständnis
Das Backlog ist unsere gemeinsame Orientierung für die weitere Produktentwicklung mit klaren nächsten Schwerpunkten.
Hilft Mehrwert zu liefern
Über die klare Priorisierung hilft uns ein Product Backlog den Fokus auf die richtigen Dinge zu legen.
Hilft harte Entscheidungen zu treffen
Aus der Kombination von Lieferfortschritt und Priorisierung des Backlogs wird schnell klar, was realistisch ist. Dies unterstützt uns auch harte Prioritätsentscheidungen zu treffen.
Diese 3 Sachen solltest du unbedingt verstehen
Nur wenn du diese 3 Dinge verstanden hast, seit ihr in der Lage Product Backlogs effektiv zu nutzen.
Die genial einfache Idee eines Backlogs
Hier gibt die ursprüngliche Nutzung von Backlogs, die das Product Backlog in Scrum inspiriert haben wichtige EInblicke.
Wie wir idealerweise mit einem Product Backlog arbeiten?
Über den Einsatz und der Einbindung des Product Backlogs in Scrum, gewinnt man dazu eine gute Idee worauf es wirklich ankommt
Was dabei im Kern ein wirklich gutes Backlog auszeichnet
Erst der richtige Aufbau eines Product Backlogs macht es effektiv
Mehr dazu in diesem Artikel!
Ergänzend zu diesem Artikel, haben wir die Informationen zum Product Backlog in dieser Podcast-Folge aufgearbeitet:
Klicken Sie auf den unteren Button, um den Inhalt von Spotify zu laden.
Die Idee des Backlogs: Der Ursprung
Backlog Definition – Ein Backlog ist eine Sammlung von Arbeitsthemen, die noch erledigt werden müssen. (Abgeleitet aus dieser Beschreibung)
Backlogs in Scrum sind inspiriert aus der Nutzung von Backlogs Finance und Logistik.
Hier werden Backlogs wie folgt genutzt:
– Best way of dealing with Backlog in Accounting
– How To Eliminate Backlogs In The Accounts Payable Process
– Backlog in Supply Chain Management
In diesen Bereichen entstehen aus der Arbeit neue zu erledigende Themen. Diese werden hier in Backlogs gesammelt und priotisiert. So stellen wir sicher das trotz immer neu aufkommender Arbeit an den richtigen Dingen gearbeitet wird.
In diesem Sinne sind Backlogs also keine statische Anforderungsliste. Sie spiegeln die aktuell vor uns liegende Arbeit wieder. So gibt uns ein Backlog die gemeinsame Orientierung die Dinge effektiv anzugehen.
Backlogs in der Agilität – So wurde die Idee aufgegriffen
Diese Herangehensweise passt gut zur agilen Arbeitsweise. Hier streben wir danach zügig aus der Lieferung minimaler Ergebnisse zu Produkt und Arbeitsweise dazu zu lernen.
Deswegen wurde die Idee des Backlogs in Scrum gleich an zwei Stellen aufgegriffen:
Product Backlog
Hier sammeln und organisieren wir alle Ideen und Änderungswünsche zum Produkt.
Sprint Backlog
Hier organisieren wir die nötigen Arbeiten im Sprint ausgerichtet auf das Sprint Ziel.
Leider werden viel zu oft Backlogs in Scrum zu Planungswerkzeugen alter Schule umgedeutet. Die Ursprungsidee war aber immer, dass sie eine dynamische Anforderungsliste ist. Geht diese verloren, kann keine effektive agile Umgebung entstehen!
Das Product Backlog in Scrum
Im Product Backlog in Scrum sammeln wir alle Ideen, Verbesserungen und Änderungswünsche die uns dabei helfen unser Produktziel zu erreichen. Dabei gibt das angestrebte Produktziel die nötige Orientierung für die Ausrichtung des Product Backlogs.
Für die effektive Organisation des Product Backlogs ist der Product Owner zuständig. Seine primäre Aufgabe ist es mit den eingesetzten Mitteln möglichst viel Mehrwert zu realisieren. Das kann kein PO für sich alleine bewerkstelligen. Deswegen befindet sich der PO im regen Austausch mit Stakeholdern und Entwickeln.
Der PO bindet die Entwickler kontinuierlich in die Pflege des Product Backlogs mit ein. Diese gemeinsame Aktivität nennt man Product Backlog Refinement. Der Fokus liegt hier allerdings nicht nur auf der Vorbereitung des kommenden Sprints. Mindestens genauso wichtig ist hier die frühe Einbindung der Entwickler zu frühen groben neuen Themen.
Das Product Backlog gibt uns im Sprint Planning eine wichtige Orientierung, was ansteht. Das ist wichtig, damit ein Scrum Team gemeinsam ein passendes Sprint Ziel abstimmen kann. Passend zum Sprint Ziel wählen wir Backlog-Items aus dem Product Backlog aus. Diese bilden mit dem Sprint Ziel das Sprint Backlog. Wozu die Entwickler ihre Herangehensweise für den Sprint abstimmen.
Im Sprint dann also das Sprint Backlog im Fokus und nicht das Product Backlog!
Im Sprint Review wird der geschaffene Arbeitsstand in den Produktausblick eingeordnet. Daraus ergeben sich neue Eindrücke für die weitere Produktentwicklung.
So hat das Sprint Review folgende Auswirkungen auf das Product Backlog:
- Nicht 100% abgeschlossene Backlog-Items gehen zurück ins Product Backlog
- Neue Ideen fließen ins Product Backlog ein
- Bestehende Ideen im Backlog abgewandelt oder sogar gelöscht
- Ausgehend von einer neuen Risikoeinschätzung wird auch oft umpriorisiert
Wobei sich die Anpassungen des Product Backlogs nicht auf das Sprint Review beschränkt. Das Product Backlog wird stetig weiterentwickelt. Es spiegelt immer unser jeweils aktuelles Verständnis wieder, was zur Erreichung des Produktziels benötigt wird.
Die Product-Backlog-Items
Als Product-Backlog-Items, kurz PBIs, bezeichnet man in Scrum einen Eintrag im Product Backlog. Ein jeder solcher Einträge schafft für sich einen Mehrwert. Das heißt, ein Product-Backlog-Item ist nicht einfach nur die Beschreibung einer Tätigkeit, sondern eines Vorhabens, was für sich auf das Produkt einzahlt.
Scrum ist ein minimales Rahmenwerk, was wir passend zum jeweiligen Kontext ausgestalten. Konsequenterweise schreibt der Scrum Guide deswegen kein Format für Backlog-Items vor.
Die meisten Scrum Teams arbeiten mit User Stories. Dies sind leichtgewichtige Anforderungen aus Nutzersicht. Ein Format, das ich selbst gern nutze, da es mit seinen “Nutzer-Glücklichmach-Items” den Nutzer ins Zentrum der Entwicklung stellt und gleichzeitig eine sehr leichtgewichtige Möglichkeit darstellt, die Arbeit für alle Beteiligten sichtbar zu machen. Sie verdichten alles was notwendig ist, um in den Sprint zu starten. Gleichzeitig ermöglichen sie es durch ihren (noch) geringen technische Bezug, den Kunden von Anfang an in die Arbeit mit einzubeziehen – und genau darum geht es in Scrum. Mehr zum Thema User Stories gibt es hier.
Alternativen zu User Stories
- Bugs
- Use Cases
- Job Stories
- Enabler Stories
- Hier könnte dein Format stehen 😉
Der Product Owner und das Backlog
Der Product Owner (PO) in Scrum ist dafür zuständig, den zu schaffenden Mehrwert des Scrum Teams zu maximieren. Sein wichtigstes Werkzeug dabei ist das Product Backlog. Über die richtige Priorisierung schafft der PO es, den Fokus auf die richtigen Dinge zu setzen, um mit möglich wenig Aufwand möglichst viel Nutzen zu erreichen.
Alleine kann ein PO dies aber nicht leisten. Der Product Owner ist auf die Zusammenarbeit mit den Stakeholdern und den Entwicklern angewiesen.
Im Austausch mit den Stakeholdern versteht der Product Owner die Bedarfe. Konsolidiert diese Wünsche in Richtung des Produktziels, um fokussiert in dieser Richtung Wert liefern zu können. Dabei hilft ein gut aufgebautes Product Backlog dabei harte Fokusentscheidungen zu treffen. Schließlich sind unsere Kapazitäten immer auch begrenzt. Da gilt es die richtigen Schwerpunkte zu setzen.
Darüber hinaus ist ein Product Owner auf die Unterstützung der Entwickler angewiesen. Schließlich muss ein PO kein technisches Know-how haben. Es gibt aber auch kein Produkt wo ein PO in ausreichender Tiefe in allen technischen Details stecken kann.
Die Aufgabe eines POs ist es deswegen nicht, die Entwicklung für das Scrum Team vorzudenken. Das ist eine typische Dysfunktion und kontraproduktiv. Ein Product Owner schaffen einen guten Ausblick, aus dem der PO die Entwicklung zusammen mit den Entwicklern ausgestaltet.
- Feedback und Ratschläge zur effektiven Ausrichtung und Ausgestaltung des Produktes
- Frühes Feedback zu groben Backlog-Items
- Identifikation von Risiken
- Einschätzung des Aufwands
- Vorschläge von Lösungsansätzen
- Herunterbrechen von Backlog-Items
- Rückmeldung, was für die Arbeit im Sprint gebraucht wird
- Bewertung und Nachjustierung der Produktentwicklung aus gelieferten Ergebnissen
So ist gute Product Ownership ein Teamsport. Der PO schafft den Rahmen, um in effektiver Co-Creation, dass richtige Produkt zu entwickeln.
Möchtest du mehr zum Product Owner erfahren?
Auf dieser Seite haben wir alle unsere Informationen zum Product Owner gebündelt. Hier findest du Antworten zu wichtigen Fragen, vertiefende Podcast-Folgen und aufbauende Artikeln.
Gute Backlogs, das zeichnet sie aus
Ohne ein Artefakt wie dem Product Backlog ist eine effektive, agile Produktentwicklung nicht denkbar.
Ein Backlog ist keine Work Breakdown Structure (WBS)!
Um zu verstehen, was ein gutes Product Backlog ausmacht, hilft es zu verstehen, was es von anderen Techniken unterscheidet.
| Product Backlog | Work Breakdown Structure (WBS) | |
| Zweck | Organisation der Entwicklung für eine explorative Produktentwicklung | Zerlegung des Projekts in kleinere, überschaubare Arbeitseinheiten |
| Verwendung | Häufig verwendet in agilen Entwicklungsmethoden wie Scrum | Wird in vielen verschiedenen Projektmanagement-Methoden verwendet |
| Arbeitsweise | Dynamisch, wird regelmäßig aktualisiert und angepasst | Statisch, Struktur wird schwerpunktmäßig zum Start erstellt |
| Veränderungen | Änderungen können jederzeit vorgenommen werden | Änderungen sind im Laufe des Projekts schwieriger und aufwendiger umzusetzen |
| Fokus | Konzentration auf die wichtigsten Funktionen oder Anforderungen des Produkts | Fokussierung auf die Aufgaben, die für die erfolgreiche Durchführung des Projekts erforderlich sind |
| Aufbau | Priorisierung wichtiger als eine strikte Hierarchie | Hierarchische Struktur mit klar definierten Arbeitspaketen |
Nur zu leicht werden alte Arbeitsweisen in der Agilität fortgeführt. Das führt oft zu unnötigen Dysfunktionen!
Typische Dysfunktionen
Alte Gewohnheiten und Missverständnisse führen oft zu ineffektiven Product Backlogs.
Hier eine Auswahl gängiger Dysfunktionen, auf die du achten solltest:
- Fehlende Übersicht: Ohne eine gemeinsame Übersicht wird es schwer, gemeinsam mit dem Product Backlog zu arbeiten
- Unspezifische Items: Drei Worte machen noch kein Backlog-Item, was andere verstehen
- Zu präskriptive Beschreibungen: Verhindert kreative Lösungen und kann die Entwicklung ineffektiver Lösungen forcieren
- Deadlines: Das Forcieren von Lieferterminen schafft oft Disengagement und Passivität
- Zu unstrukturiert: Eine Ansammlung von Tickets, durch die keiner durchschauen kann, hilft keinem weiter
- Bindet die Entwickler nicht ein: So schaffen wir oft Blindleistung, weil wichtiger Input nicht genutzt wurde
DEEP – Das zeichnet ein gutes Product Backlog aus
Bei der effektiven Nutzung und Gestaltung des Backlogs geht es darum, ausreichend detailliert zu sein, um konkret in den Sprint starten zu können. Gleichzeitig ist es aber auch wichtig, eine gute Übersicht über das zu ermöglichen, was nach den unmittelbar bevorstehenden Sprints kommt. Dabei unterscheiden sich unmittelbar bevorstehende Items in ihrer Konkretheit von denjenigen Items, die weiter in der Zukunft liegen. Man könnte das Backlog auch mit einer Reise vergleichen: Unmittelbar bevorstehende Anforderungen, wie beispielsweise die konkrete Wegbeschreibung für den Hinweg, müssen bei Antritt bekannt sein. Über den Rückweg muss ich mir zu diesem Zeitpunkt in dieser Tiefe in der Regel noch keine Gedanken machen. Es genügt erstmal zu wissen, wann der Rückweg angetreten wird. Auch die Abfolge einzelner Schritte muss am Anfang der Reise feststehen. Muss ich zuerst nach A oder B um dann nach C zu gelangen? Ebenso soll auch das Product Backlog eine Abfolge bzw. eine Priorisierung verdeutlichen.
Ein gutes Backlog muss demnach
- konkret und klar Aufschluss darüber geben, was als nächstes ansteht
- einen groben Ausblick über zukünftige Schritte geben
- eindeutig priorisiert sein
Durch diese strategische Übersicht ist es möglich, ein klares Sprint-Ziel festzulegen und konkret in den Sprint zu starten. Dennoch muss man sich bei der Arbeit mit dem Product Backlog stets vor Augen halten, dass niemals von Anfang an alle Informationen bekannt sein können. Entsprechend ist ein Backlog dynamisch und wird kontinuierlich gepflegt.
Statt lebloser Retrospektiven gemeinsam Verbesserungen vorantreiben
Lasst uns gemeinsam in diesem kostenlosen Scrum Master Dojo austauschen und strukturiert neue Ansatzpunkte finden, um als Scrum Master einen Unterschied zu machen.
Montag
14.08.
18:15-20:00
Vier „Faustregeln“ für ein gutes Backlog
1. Menge: Fünf bis zehn Items für den Sprint sind optimal.
Die Items sollten so eingeteilt werden, dass ca. fünf bis zehn in den Sprint einfließen können. Dadurch kann sichergestellt werden, dass weder zu wenige noch zu viele Items zur Bearbeitung vorliegen. Kümmert sich das Team um weniger als fünf Items, kann sich dies schnell negativ auf Auswertungen oder gar auf die Motivation der Teammitglieder auswirken. Werden beispielsweise nur zwei von vier Items nicht geschafft, gelten 50% des Sprints als nicht erledigt. Die Auswertung verschlechtert sich erheblich und die Motivation des Teams leidet. Darüber hinaus kann das Team bei weniger als fünf Items keine strategisch sinnvollen Entscheidungen bei der Item-Auswahl treffen. Entscheidet man sich hingegen dazu, mehr als zehn Items in den Sprint aufzunehmen, kann schnell die Übersicht verloren gehen. Fünf bis zehn Items stellen daher meiner Meinung nach die passende Menge dar.2. Auswahl: Die eineinhalb- bis zweifache Menge an Items bieten.
Um dem Team eine sinnvolle Auswahl der Items sowie einen Ausblick zu ermöglichen, sollte dem Team das eineinhalb- bis zweifache an Items vorliegen. Zusammenhänge und Synergien können so besser bei der Auswahl der Items berücksichtigt werden.3. Ausblick: Ein strategischer Ausblick schafft Orientierung.
Ein Backlog sollte dem Team auch immer einen strategischen Ausblick auf zukünftige Aktivitäten geben. Basierend auf diesen Informationen ist das Team in der Lage, sinnvolle Items zu wählen und Sprint-Ziele festzulegen.4. Überblick: Die Arbeit mit max. 120 Items reduziert die Komplexität.
Ein Backlog sollte nicht mehr als 120 Items beinhalten. Konkret bedeutet das, dass es weder eine Ansammlungen von vielen sehr kleinteiligen Items sein sollte, noch dass große Items gemieden werden sollten. Es geht vielmehr darum, größere Items früh zu erkennen und im Verlauf schrittweise herunterzubrechen. Ebenso ist es möglich, Items die weiter in der Zukunft liegen, der Übersichtlichkeit zuliebe zu gruppieren.
Product Backlog Refinement
Das Backlog Refinement bedeutet die Pflege des Backlogs durch den Product Owner und das Entwicklungsteam. Früher wurde für das Refinement auch der Begriff Grooming verwendet. Dieser wurde aus dem American English übernommen. Er wurde jedoch abrupt wieder abgeschafft nachdem deutlich wurde, dass der Begriff im British English eine negative Bedeutung hat. In einigen Quellen wird er jedoch noch immer als Bezeichnung für die Backlog-Pflege (Backlog Refinement) verwendet.
Der Product Owner und sein Team.
Der Product Owner ist grundsätzlich für die Backlog-Pflege verantwortlich. Jedoch macht es keinen Sinn, dass dieser sich völlig isoliert darum kümmert. Ein guter Product Owner bindet sein Team frühzeitig und regelmäßig in die Pflege mit ein. Konkret bedeutet das, dass sie frühzeitig und gemeinsam Items besprechen. Dazu gehört auch, durch Schätzen der einzelnen Items den daraus entstehenden Dialog zu nutzen und durch effektives Splitting die Insights der Entwickler für die Backlog-Pflege nutzbar zu machen (mehr zum Thema Schätzen findest du hier.)
Backlog Refinement: Wann genau?
Das Backlog Refinement ist kein Scrum Ereignis, da dem Team völlig freigestellt wir, wann es diese Backlog-Pflege durchführt. Basierend auf der Annahmen, das Product Backlog könne vorausschauend bei der Planung des Sprints gepflegt werden, war diese ursprünglich Teil des Sprint Plannings. Neben der Festlegung des Sprint-Ziels und der Konkretisierung der Items für den Sprint wurden im Planning zusätzlich die Backlog Items gepflegt. Weil in den meisten Teams dieser Doppelfokus als zu störend wahrgenommen wurde, hat sich in der Praxis die Backlog-Pflege außerhalb des Sprint Plannings etabliert. Jedes Team muss dabei für sich selbst entscheiden, was am meisten Sinn macht. Es kann sich beispielsweise dazu entscheiden, das Backlog jeden Freitag- oder Mittwochnachmittag zu pflegen, wenn kein Sprint-Wechsel stattfindet. Es kann sich aber auch dazu entscheiden, die Backlog-Pflege jeden Tag für 15 Minuten nach dem Daily zu erledigen. Das positive an dieser höheren Taktung ist, dass sie dem Product Owner dabei hilft, regelmäßig Meinungen vom Team abzuholen. Wofür du dich auch entscheidest: Wichtig dabei ist, dass es dem Team weiterhin möglich ist, sich auf den Sprint zu konzentrieren.
Ich hoffe, ich konnte mit meinen Tipps neue Impulse liefern, wie du dein Product Backlog gestalten und effektiv nutzen kannst. Hast du Fragen oder Anmerkungen? Ich freue mich immer über Feedback.
Zusammenfassung
Ein Backlog ist mehr als nur eine Ansammlung von Anforderungen. Es ist unser strategischer Ausblick, mit dem wir als Scrum Team das Produkt gemeinsam ausgestalten. Anhand von wenigen Faustregeln hinsichtlich Menge, Auswahl, Ausblick und Überblick, kann die Backlog-Pflege effektiver gelebt werden. Es ist essentiell, dass der Product Owner das Team in die Backlog Pflege mit einbindet.
Möchtest du mehr zum Product Owner erfahren?
Auf dieser Seite haben wir alle unsere Informationen zum Product Owner gebündelt. Hier findest du Antworten zu wichtigen Fragen, vertiefende Podcast-Folgen und aufbauende Artikeln.
Ergänzende Artikel und Tipps
Hier gibt Roman Pichler 10 Tipps zur optimalen Nutzung eines Product Backlogs.
Ergänzend dazu ist Roman hier zu Gast im Podcast “Die Produktwerker” und spricht hier über “Von der Produktstrategie zum Product Backlog”.
Mike Cohn hat darüber hinaus in diesem Artikel aufgearbeitet, warum ein gutes Produkt Backlog ähnlich aufgebaut ist wie ein Eisberg, und gibt hier Tipps für den Frühjahrsputz in einem wuchernden Product Backlog.
