14 Produkt-Backlog Prinzipien, die Ihrem Scrum-Team zum Erfolg verhelfen
In Kürze: 14 Produkt-Backlog Prinzipien
Entgegen der landläufigen Meinung hat der Product Owner keine diktatorischen Befugnisse, was die Zusammensetzung und Reihenfolge des Produkt-Backlogs angeht. Stattdessen basiert Scrum auf einem ausgeklügelten System von Checks & Balances, Zusammenarbeit und gemeinsamer Entscheidungsfindung, um das Risiko zu mindern, dass sich der Product Owner in seine Lösung verliebt und nicht in das Problem des Kunden. Erfahren Sie mehr über die wichtigsten Produkt-Backlog Prinzipien: Von der Größe und dem Wachstum des Produkt-Backlogs bis hin zur Frage, ob ein Produkt-Backlog überhaupt notwendig ist. (Einige Lean-Experten bestreiten, dass dessen Existenz gerechtfertigt ist.)
🗳 Update: Join the poll and its lively discussion on LinkedIn.
🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 35.000 Abonnenten anschließen.
🎓 Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil!
📅 💯 🇬🇧 September 27, 2022: Join 200-plus peers at the 45th Hands-on Agile Meetup: FAST: An Innovative Way to Scale with James Shore.
Das Produkt-Backlog nach dem Scrum Guide
Lassen Sie uns zunächst einen Blick auf die aktuelle Ausgabe des Scrum Guide werfen, um die Produkt-Backlog Prinzipien besser zu verstehen:
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
[Product Owner] decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.
The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.
Quelle: Scrum Guide 2020.
Eine vollständige Übersicht der Produkt-Backlog Zitate aus dem Scrum Guide finden Sie im Scrum Guide Reordered 2020.
Scrum, das ein taktisches Framework ist, ist gut darin, validierte Hypothesen in Produkt-Inkremente zu überführen, um die Lernschleife zu schließen. Hierzu zählen die Überprüfung der anfänglichen Annahmen, der Entscheidungsprozess zur Erstellung eines Inkrements und die anschließende Adaption des Produkt-Backlogs zur Vorbereitung für den nächsten Sprint.
Aber letztendlich besteht die erste Herausforderung in einer komplexen Umgebung darin, herauszufinden, was es überhaupt wert ist, gebaut zu werden. Ein erfolgreiches Scrum-Team muss sich daher von der Vorstellung lösen, dass der Product Owner auf wundersame Weise herausfindet, wie im besten Interesse der Kunden, des Unternehmens und des Teams vorgegangen werden soll. Versuchen Sie stattdessen, jeden in den Aufbau eines Systems einzubinden, mit dem es gelingt, validierte Hypothesen darüber, was wertvoll sein könnte, in das Produkt-Backlog einzuspeisen. (Erfahren Sie hierzu mehr: Produkt-Backlog Refinement — ein kritischer Erfolgsfaktor für Scrum Teams.)
Mit anderen Worten: Das bloße Vorhandensein eines Produkt-Backlogs ist keine Erfolgsgarantie, denn Scrum ist ebenso gut geeignet, um Dinge effektiv zu entwickeln, die kein Kunde will.
Cannot see the form? Please click here.
Produkt-Backlog Prinzipien
Dies sind meine 14 Produkt-Backlog Prinzipien für erfolgreiche Scrum-Teams:
- Das Produktziel bestimmt das Ergebnis: Das Produkt-Backlog spiegelt das Produktziel des Scrum-Teams wider. Es ist nicht nur ein Verzeichnis oder ein Buchhaltungssystem für alle Anforderungen, die dem Team vorgelegt werden. Da sich Pläne in komplexen Umgebungen wandeln, ändert sich auch die Interpretation des Produktziels des Teams und folglich auch die Zusammensetzung und Reihenfolge der Elemente des Produkt-Backlogs. Produkt-Backlogs sind per Definition dynamisch.
- Vorrechte des Product Owners: Product Owner werden dafür bezahlt, den Wert der Arbeit der Entwickler im Namen der Kunden und des Unternehmens zu maximieren – im Rahmen der gegebenen Einschränkungen. Sie tun dies, indem sie das Produkt-Backlog auf der Grundlage von Inhalt und Reihenfolge verwalten. Entgegen der landläufigen Meinung bedeutet dies jedoch nicht, dass sie auch diktatorische Befugnisse haben. Scrum ist ein delikates System von Checks & Balances; daher sollten die anderen Teammitglieder auch jeden Vorschlag des Product Owners infrage stellen: Gibt es nichts Wichtigeres, was wir in Angriff nehmen können, Product Owner?
- Das Produkt-Backlog-System: Das Produkt-Backlog ist ein wichtiger, aber nicht der einzige Teil eines Systems, das den Fluss wertschöpfender Arbeit durch das Scrum-Team organisiert. Der Teil der Produktentdeckung, der validierte Hypothesen über wahrscheinlich wertvolle Arbeiten dem Produkt-Backlog zuführt, verdient die gleiche Aufmerksamkeit.
- Risikominimierung: Der Zweck des Produkt-Backlogs ist die Risikominimierung. An und für sich repräsentiert das Produkt-Backlog kaum einen Mehrwert.
- #KeinePolitik: Es ist verlockend, das Produkt-Backlog als Beruhigungspille für lästige Interessenvertreter zu verwenden. Aber nur Transparenz und Respekt lösen dieses Problem. Wenn das Scrum-Team nicht daran denkt, an einer Anforderung zu arbeiten, sagen Sie es diesen Stakeholdern. Wenn Sie stattdessen diese nutzlosen Anforderungen in das Produkt-Backlog aufnehmen, nur um sie dort verstauben zu lassen, so verschieben Sie nur dieses notwendige Gespräch. Und wenn es dann endlich so weit ist, können Sie sicher sein, dass Emotionen dieses Gespräch belasten werden.
- Wachstum: Wenn Ihr Produkt-Backlog schneller wächst, als das Scrum-Team Product-Backlog-Elemente liefern kann, sind Sie wahrscheinlich auf dem besten Weg, eine Feature-Fabrik zu werden.
- Umfang: Jedes Produkt-Backlog, das mehr Arbeit enthält, als das Scrum-Team in zwei bis vier Sprints bewältigen kann, ist m. E. Verschwendung. Produkt-Backlogs skalieren nicht. (Einige Lean-Experten argumentieren sogar, dass die bloße Existenz eines Produkt-Backlogs bereits Verschwendung bedeutet.)
- Grenzkosten: Das Hinzufügen eines Eintrags im Produkt-Backlog kann mit wenig Aufwand verbunden sein. Es mag den Anschein haben, dass das Erweitern des Produkt-Backlogs kostenlos und daher eine hervorragende Strategie ist, um nichts Wichtiges zu „verpassen“. Das Problem ist jedoch die Anhäufung vermeintlich „kostenloser“ Einträge, da die Kosten für die Bearbeitung immer größerer Produkt-Backlogs exponentiell ansteigen.
- Ideenspeicher: Produkt-Backlogs scheinen attraktive Orte zu sein, um sie mit Ideen, Gedanken und Skizzen zu füllen. Irgendwo müssen sie ja hin, nicht wahr? Dem stimme ich zu, aber missbrauchen Sie das Produkt-Backlog nicht für diesen Zweck, denn es stellt einen Ort höherer Wahrscheinlichkeit dar, dass seine Einträge auch tatsächlich in Inkremente überführt werden. Stellen Sie daher sicher, dass Sie dem Produkt-Backlog nur Einträge hinzufügen, die das Scrum-Team zuvor validiert hat.
- Von Nutzen des Löschens: Löschen Sie Produkt-Backlog-Elemente, die das Scrum-Team seit mehr als acht Wochen nicht mehr bearbeitet hat. Höchstwahrscheinlich sind sie ohnehin nur Rauschen. Wenn sie jedoch stattdessen ein Signal sein sollten, werden sie sicherlich wieder auftauchen.
- Keine Garantie: Ein Produkt-Backlog spiegelt die beste Nutzung der Zeit des Scrum-Teams zu einem bestimmten Zeitpunkt wider. Es ist eine Momentaufnahme einer komplexen, dynamischen Situation. Wenn eine Anforderung in das Produkt-Backlog aufgenommen wird, heißt das also nicht, dass das Team sie auch bauen wird. Vielleicht gibt es stattdessen etwas Wertvolleres zu wählen.
- Abarbeiten des Produkt-Backlogs: Das Scrum-Team realisiert das Produkt-Backlog nicht auf der Grundlage seiner Reihenfolge zum Zeitpunkt der Sprintplanung. Stattdessen legt das Scrum-Team gemeinsam das Sprintziel fest, das dann den Inhalt des Sprint-Backlogs bestimmt. In den meisten Fällen kann das Produkt-Backlog Elemente zum Sprint-Backlog beitragen. Es gibt jedoch keinen Automatismus. Falls erforderlich, erstellen die Entwickler alle für die Erreichung des Sprint-Ziels erforderlichen Arbeitsaufgaben an Ort und Stelle. Wenn dies eher die Regel als die Ausnahme ist, fragen Sie sich bitte, warum Sie Zeit mit der Erstellung eines Produkt-Backlogs verbringen. Hören Sie dann doch einfach damit auf.
- Vertrauensbildende Maßnahmen: Nichts ist besser geeignet, um Vertrauen bei den Stakeholdern aufzubauen, als die Lieferung wertvoller Inkremente. Verwenden Sie das Produkt-Backlog also nur, um das Scrum-Team in dieser Funktion zu unterstützen.
- Das Abarbeiten von Plänen: Wir werden nicht dafür bezahlt, umfassende Produkt-Backlogs zu erstellen, zum Beispiel im Rahmen der Vorabplanung für die nächsten zwölf Monate. Das emsige Hinzufügen von Produkt-Backlog-Einträgen in Jira schafft keinen Wert, sondern gefährliches Rauschen; denken Sie z. B. an die Folgen der Verlustangst. Leider lässt sich das bloße „Befolgen eines Plans“ viel leichter verkaufen, wenn Ihr Produkt-Backlog eine epische Größe erreicht hat und damit als Vermögenswert betrachtet wird. Dennoch ist es nicht mehr als ein Werkzeug; es hat keinen Wert an sich.
Fazit:
Das Produkt-Backlog kann ein entscheidendes Artefakt auf dem Weg zum Erfolg Ihres Scrum-Teams sein. In einer komplexen Umgebung, in der es keine Experten gibt, die auf alle Probleme eine Antwort wissen, reicht es jedoch nicht aus, einfach alle Anforderungen in ein Jira-Projekt zu packen, die Ihnen vorgelegt werden. Wichtiger als die Liste selbst ist es, einen Prozess zu schaffen, um nur validierte Hypothesen dem Produkt-Backlog hinzuzufügen. Zu diesem Zweck sollten Sie die oben genannten Produkt-Backlog Prinzipien berücksichtigen, damit Sie diese kreative Herausforderung erfolgreich meistern können.
Welche Produkt-Backlog Prinzipien haben sich für Sie bewährt? Teilen Sie uns diese bitte in den Kommentaren mit.
📖 Produkt-Backlog Prinzipien — Weitere Lektüre
Produkt-Backlog Refinement — ein kritischer Erfolgsfaktor für Scrum Teams
20 Sprint Planning Anti-Patterns
24+2 Daily Scrum Anti-Patterns
15 Sprint Review Anti-Patterns
21 Sprint Retrospektive Anti-Patterns
Download the 66 Scrum Master Interview Questions for free.
📅 Professional Scrum-Schulungen nach Scrum.org, Workshops und Events
Lernen Sie, wie Sie Produkt-Backlog Prinzipien meistern können! Sie können sich Ihren Platz für Scrum-Schulungen, Workshops und Meetups direkt sichern, indem Sie dem entsprechenden Link in der Tabelle unten folgen:
Alle kommenden Professional-Scrum-Klassen finden Sie hier.
Sie können Ihren Platz für die Schulung direkt buchen, indem Sie den entsprechenden Links zum Ticketshop folgen. Sollte der Beschaffungsprozess Ihrer Organisation einen anderen Einkaufsprozess erfordern, wenden Sie sich bitte direkt an die Berlin Product People GmbH.
✋ Nicht versäumen: Lernen Sie mehr über Produkt-Backlog Prinzipien im 12.000-köpfigen „Hands-on Agile Slack Team“
Ich lade Sie ein, sich dem „Hands-on Agile“ Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft von agilen Praktikern aus der ganzen Welt zu genießen.
Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos.
Unterstützen Sie Ihr Scrum-Team mit Produkt-Backlog Prinzipien. Laden Sie den kostenlosen Scrum Anti-Patterns Guide herunter:
Tags: Product Backlog, Product Backlog Verfeinerung, Product Owner, Scrum First Principles
