28 Product Backlog Anti-Patterns

Scrum Anti-Patterns Guide — Berlin Product People

In Kürze: 28 Product Backlog Anti-Patterns

Scrum ist ein einfaches, aber hinreichendes Framework für die Entwicklung neuer Produkte, vorausgesetzt, man identifiziert im Voraus, was es sich lohnt zu bauen. Aber auch nach einer erfolgreichen Produkterkundungsphasen kann es einem Scrum Team schwer fallen, das Richtige zu erreichen, wenn das Product Backlog nicht den Anforderungen entspricht: “Garbage in, Garbage out” — wie man so schön sagt. Der folgende Artikel zeigt 28 Product Backlog Anti-Patterns — einschließlich des Product Backlog Verfeinerungsprozesses — auf, die den Erfolg Ihres Scrum Teams limitieren.

28 Product Backlog Anti-Patterns — Berlin Product People GmbH

Das Product Backlog gemäß Scrum Guide

Werfen wir zunächst einen Blick in die aktuelle Ausgabe des Scrum Guide zum Product Backlog:

“Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above-described refining activities.

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.”

Source & Copyright: ©2016 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible here and also described in summary form.

Typische Product Backlog Anti-Patterns

Obwohl relativ simple, leidet der Prozess der Erstellung und Verfeinerung eines Product Backlogs oft unter verschiedenen Anti-Patterns. Ich habe fünf verschiedene Kategorien für Product Backlog Anti-Patterns identifiziert:

Allgemeine Product Backlog Anti-Patterns

  1. Priorisierung durch einen Stellvertreter: Ein einzelner Stakeholder oder ein Komitee von Stakeholdern priorisiert das Product Backlog. (Die Leistungsfähigkeit von Scrum basiert auf der starken Position des Product Owners. Sie oder er ist die einzige Person, die entscheidet, welche Anforderungen zu Product-Backlog-Einträgen werden. Somit entscheidet auch der Product Owner über die Priorität. Wenn man diese Ermächtigung des PO eliminiert, verwandelt sich Scrum in einen ziemlich robusten Wasserfall 2.0 Prozess.)
  2. 100% im Voraus: Das Scrum-Team erstellt ein Product Backlog, welches das gesamte Projekt oder Produkt im Vorfeld abdeckt, da der Umfang des Releases begrenzt ist. (Frage: Wie kann man sicher sein, heute zu wissen, was man in sechs Monaten liefern soll?)
  3. Überdimensioniert: Der Product Backlog enthält mehr Einträge, als das Scrum-Team innerhalb von drei bis vier Sprints liefern kann. (Auf diese Weise erzeugt der Product Owner unnötige Arbeit, indem er oder sie Aufgaben und Probleme sammelt, die möglicherweise nie auftreten.)
  4. Veraltete Einträge: Der Product Backlog enthält Einträge, die seit sechs bis acht Wochen oder länger nicht mehr ansehen wurden. (Das ist typischerweise die Länge von zwei bis vier Sprints. Wenn der Product Owner Product-Backlog-Einträge hortet, besteht das Risiko, dass ältere Einträge veralten und somit die zuvor investierte Arbeit des Scrum-Teams umsonst war.)
  5. Eine Schätzung für jeden Eintrag: Alle Einträge des Product Backlog sind detailliert ausgearbeitet und geschätzt. (Das ist zu viel Vorleistung und birgt das Risiko einer Fehlallokation der Zeit des Scrum-Teams.)
  6. Komponenten-basierte Einträge: Die Product Backlog Elemente werden horizontal nach Komponenten und nicht vertikal nach End-to-End Merkmalen aufgeteilt. (Dies kann entweder durch die Organisationsstruktur verursacht werden. Dann sollte man einen Wechsel zu cross-funktionalen Teams in Erwägung ziehen, um die Leistungsfähigkeit des Teams zu verbessern. Andernfalls benötigen das Team – und der Product Owner – einen Workshop zum Schreiben von User Stories).
  7. Fehlenden Akzeptanzkriterien: Im Product Backlog gibt es Einträge ohne Akzeptanzkriterien. (Es ist nicht notwendig, zu Beginn des Refinements Akzeptanzkriterien zu haben, obwohl sie die Aufgabe wesentlich erleichtern würden. Am Ende sollten jedoch alle Product-Backlog-Einträge dem Standard für “Ready” entsprechen, und Akzeptanzkriterien sind Teil dieser Vereinbarung.)
  8. Nicht mehr als ein Titel: Der Product Backlog enthält Einträge, die nur aus einem Titel bestehen.
  9. Einträge sind zu detailliert: Es gibt Einträge mit einer umfangreichen Liste von Akzeptanzkriterien. (Das ist das andere Extrem: Der Product Owner deckt jeden Ausnahmefall ab, ohne mit dem Entwicklungsteam zu verhandeln. In der Regel sind drei bis fünf Akzeptanzkriterien mehr als ausreichend.)
  10. Weder Themen noch Epics: Der Product Backlog ist nicht nach Themen oder Epics strukturiert. (Dies erschwert es, einzelne Einträge mit der Vision bzw. Strategie des Unternehmens abzustimmen. Der Product Backlog sollte keine Ansammlung von isolierten Aufgaben oder eine große To-Do-Liste sein.)
  11. Keine Experimente: Der Product Backlog enthält nur wenige bis keine Spikes. (Dies korreliert oft mit einem Team, das zu viel Zeit damit verbringt, über potenzielle Probleme zu diskutieren, anstatt sie mit einem Spike als Teil eines iterativen Prozesses zu erforschen.)
Jetzt den Scrum-Anti-Patterns-Guide kostenlos herunterladen

Anti-Patterns auf Portfolio- und Roadmap-Ebene

  1. Roadmap? Der Product Backlog spiegelt die Roadmap nicht wider. (Der Product Backlog soll nur für die ersten zwei oder drei Sprints detailliert genug sein. Darüber hinaus sollte sich der Product Backlog eher auf Themen und Epen aus der Product Roadmap konzentrieren. Wenn diese nicht verfügbar sind, ist es wahrscheinlich, dass der Produkt-Backlog zu granular wird.)
  2. Jährliche Roadmaps: Der Portfolio-Plan des Unternehmens sowie der Release-Plan oder die Produkt-Roadmap werden einmal jährlich im Voraus erstellt. (Wenn der Product Backlog auf diese Pläne ausgerichtet bleibt, wird Waterfall-Planung durch die Hintertür eingeführt. Agile Planung ist immer „kontinuierlich“. Auf Portfolioebene muss der Plan mindestens alle drei Monate überarbeitet werden, idealerweise erfolgt dies kontinuierlich mit einer passenden Kadenz.)
  3. Roadmaps bleiben ein Geheimnis: Die Portfolio-Planung und der Release-Plan bzw. die Produkt-Roadmap sind nicht für jedermann sichtbar. (“If you do not know where you are going any road will get you there”: Diese Informationen sind für jedes Scrum-Team von entscheidender Bedeutung und müssen jederzeit für alle zugänglich sein. )
  4. China in your hand: Die Portfolio-Planung und der Release-Plan bzw. die Produkt-Roadmap werden nicht als erreichbar und glaubwürdig angesehen. (Wenn sich dies im Product Backlog widerspiegelt, ist die Arbeit an User Stories wahrscheinlich eine Verschwendung.)

Product Backlog Anti-Patterns des Product Owner

  1. Ideenspeicher: Der Product Owner nutzt das Product Backlog als Ideenspeicher. (Diese Praxis bläht den Product Backlog auf, kann zu kognitiver Überlastung führen und macht die Abstimmung mit dem „Big Picture“ auf Portfolio-Management- und Roadmap-Planungsebene sehr schwierig.)
  2. Teilzeit-Product Owner: Der Product Owner arbeitet nicht täglich am Product Backlog. (Das Product Backlog muss zu jedem Zeitpunkt die bestmögliche Nutzung der Ressourcen des Entwicklungsteams darstellen. Eine wöchentliche Aktualisierung vor dem nächsten Refinement reicht nicht aus, um diese Anforderung zu erfüllen.)
  3. Kopieren & Einfügen-PO: Der Product Owner erstellt Einträge, indem er oder sie Anforderungsdokumente, die von Stakeholdern erhalten werden, in kleinere Stücke zerlegt (dieses Szenario trug dazu bei, den Spitznamen „Ticket Monkey“ für den Product Owner zu prägen. Die Erstellung von User Stories ist hingegen eine Teamübung.)
  4. Dominanter PO: Der Product Owner erstellt Product-Backlog-Einträge, indem er nicht nur das „Warum“, sondern auch das „Wie“ und das „Was“ liefert. (Das Entwicklungsteam beantwortet die Frage nach dem „Wie“ – der technischen Umsetzung -, und sowohl das Entwicklungsteam als auch die PO arbeiten an der Frage nach dem Was“ zusammen: Welcher Umfang ist notwendig, um den gewünschten Zweck zu erreichen.)
  5. INVEST? Der Product Owner wendet das INVEST-Prinzip von Bill Wake nicht auf User Stories an.
  6. Einträge zu detailliert: Der Product Owner investiert zu viel Zeit im Voraus in User Stories, die in Folge viel zu detailliert sind. (Wenn ein Eintrag final aussieht, sehen die Teammitglieder möglicherweise nicht die Notwendigkeit, sich an dem weiteren Refinement zu beteiligen. Auf diese Weise reduziert eine „fette“ User Story das Engagement des Teams und gefährdet die Schaffung eines gemeinsamen Verständnisses. Übrigens geschah dies nicht in den Tagen, als wir noch Karteikarten zu diesem Zweck verwendeten haben.)
  7. Wie Team? Der Product Owner bezieht nicht das gesamte Scrum-Team in den Refinement-Prozess ein, sondern verlässt sich nur auf den „Lead Engineer“ (oder ein anderes Mitglied des Teams unabhängig von den anderen).
  8. „Schaffe ich schon allein” Product Owner: Der Product Owner bezieht weder Stakeholder noch Fachleute in den Refinement-Prozess ein. (Ein Product Owner, der glaubt, entweder allwissend oder ein Kommunikationszentrale zu sein, ist ein Risiko für den Erfolg des Scrum-Teams.)

Anti-Patterns des Entwicklungsteams

  1. Unterwürfiges Entwicklungsteams: Das Entwicklungsteam folgt unterwürfig den Anforderungen des Product Owners. (Den Product Owner zu fragen, ob seine Auswahl an Themen die beste Nutzung der Zeit des Entwicklungsteams ist, ist ein wichtige Verpflichtung jedes Teammitglieds: Warum sollen wir diese Funktion entwickeln?)
  2. Technische Schulden? Das Entwicklungsteam fordert keine ausreichenden Ressourcen, um technische Schulden und Fehler zu beheben. (Als Faustregel gilt, dass 25% der Ressourcen in jedem Sprint zur Behebung von Fehlern und zur Überarbeitung der Codebasis zugewiesen werden.)
  3. Keine Pufferzeiten: Das Entwicklungsteam fordert vom Product Owner keine 20% Pufferzeit. (Dies überschneidet sich mit der Sprint-Planung und der Prognose des Teams. Die Pufferzeit kann jedoch nicht früh genug angegangen werden. Wenn die Kapazität eines Teams immer zu 100 % ausgelastet ist, nimmt seine Leistung mit der Zeit ab. Jeder wird sich darauf konzentrieren, seine Aufgaben zu erledigen. Es bleibt weniger Zeit, um andere Teammitglieder zu unterstützen. Kleine Probleme werden nicht mehr sofort gelöst. Und schließlich wird die Einstellung „ich bin beschäftigt“ die Schaffung eines gemeinsamen Verständnisses zwischen allen Teammitgliedern negativ beeinflussen.) Product Backlog Anti-Patterns — Utilization and Capacity Planning

Product Backlog Anti-Patterns des Scrum-Teams

  1. Keine Zeit für Refinement: Das Scrum-Team verfügt nicht über genügend Refinement-Sitzungen, was zu einem qualitativ schlechten Backlog führt. (Der Scrum Guide empfiehlt, bis zu 10% der Zeit des Scrum-Teams mit dem Refinement des Product Backlogs zu verbringen. Und dies ist eine gute Geschäftsentscheidung: Nichts ist teurer als eine Funktion, die keinen Wert in den Augen der Kunden hat.)
  2. Zuviel Refinement: Das Scrum-Team hat zu viele Refinement-Sitzungen, was zu einem zu detaillierten Product Backlog führt. (Zu viel Refinement ist auch nicht sinnvoll.)
  3. Keine Definition of Ready: Das Scrum-Team hat keine „Definition of Ready“ geschaffen, an welcher sich Product Backlog-Einträge orientieren müssen, bevor sie für einen Sprint ausgewählt werden können. (Eine einfache Checkliste wie die „Definition of Ready“ kann die Arbeit des Scrum-Teams erheblich erleichtern. Sie wird sowohl die Qualität der resultierenden User Stories als auch die Zusammenarbeit im Team im Allgemeinen verbessern.)

Fazit

Selbst in dem Fall, in dem Sie erfolgreich identifiziert haben, was als nächstes gebaut werden soll, wird Ihr Product Backlog sowie sein Refinement-Prozess wahrscheinlich Potential für Verbesserungen bieten. Involvieren Sie es einfach das Team und gehen Sie auf mögliche Anti-Patterns im Product Backlog ein.

Fehlen Product Backlog Anti-Patterns, die Sie selbst beobachtet haben? Bitte teilen Sie uns diese in den Kommentaren mit.

Das Video des Webinars zum Thema Product Backlog Anti-Patterns

Die Aufzeichnung meines Webinars über Product Backlog Anti-Patterns ist auf Youtube verfügbar:

Anmerkung: Wenn der Browser das Video nicht automatisch startet, klicken Sie hier, um die Wiedergabe des Webinars über Product Backlog Anti-Patterns direkt auf Youtube zu sehen.

Das Slide Deck des Product Backlog Anti-Patterns Webinars

Das Slide Deck des Product Backlog Anti-Patterns Webinars ist ebenfalls verfügbar:

Wenn das Slide-Deck in diesem Browserfenster nicht funktioniert, klicken Sie bitte hier, um das Slide-Deck des Webinars „Produkt Backlog Anti-Patterns“ direkt auf Slideshare anzusehen. Dort können Sie auch ein PDF des Slide-Decks herunterladen.

Weitere Blogposts

Umfrageergebnisse: Wie Scrum Master Probleme lösen.

Das Professional Scrum Master Trainings in 2019.

Tags: Backlog Refinement, Product Backlog, Scrum, Scrum Anti-Patterns

Leave a reply

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.