28 Produkt-Backlog Anti-Patterns 🇩🇪

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 Discovery-Phase 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.

🗞 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 34.000 Abonnenten anschließen.

🎓 Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil!

Das Product Backlog gemäß Scrum Guide

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

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 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.

Quelle & Copyright: ©2020 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.)

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 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 im Artikel Product Backlog Anti-Patterns, die Sie selbst beobachtet haben? Bitte teilen Sie uns diese in den Kommentaren mit.

✋ Nicht versäumen: Lernen Sie mehr über Scrum in der 11.000-köpfigen „Hands-on Agile“ Slack-Community

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.

Weitere Artikel

27 Sprint Anti-Patterns

21 Sprint Retrospektive Anti-Patterns

20 Sprint Planning Anti-Patterns

Weitere Artikel über Scrum Anti-Patterns

Download the Scrum Anti-Patterns Guide for free