27 Produktbacklog Anti-Patterns 🇩🇪

In Kürze: 27 Product Backlog Anti-Patterns

Scrum ist ein taktisches Framework für die Entwicklung von Produkten, vorausgesetzt, Sie erkennen im Voraus, was es wert ist, entwickelt zu werden. Aber selbst nach einer erfolgreichen Produktentdeckungsphase, neudeutsch: Product Discovery, kann es Ihnen schwer fallen, das Richtige auf die Beine zu stellen, wenn Ihr Product Backlog der Aufgabe nicht gewachsen ist: Garbage in, Garbage out. Der folgende Artikel zeigt 27 gängige Product Backlog Anti-Patterns — auch für den Produktbacklog-Verfeinerungsprozesses — auf, die den Erfolg Ihres Scrum-Teams beschränken.

🗞 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!

📅 Nehmen Sie am 30. Mai 2022 teil—wir sind bereits 150 Teilnehmer: HoA #42: The Skinny on Lean Roadmapping and OKRs w/ Janna Bastow.

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: Scrum Guide 2020.

Da es sich bei Scrum um ein taktisches Framework handelt, ist es gut geeignet, validierte Hypothesen über wertvolle Features effektiv für die Kunden zu erstellen, um den Lernprozess abzuschließen. Dies ermöglicht die Inspektion der ursprünglichen Annahmen und des Entscheidungsprozesses zur Erstellung eines Inkrements und die anschließende Anpassung der Vorbereitungen für den nächsten Sprint.

Scrum ist hingegen nicht konzipiert, Hypothesen zu formulieren und Experimente durchzuführen, sie zu validieren oder zu falsifizieren, was man auch als Produktentdeckung bzw. Product Discovery bezeichnet. Product Discovery ist keine Taktik, sondern Teil des operativen Bereichs, der das Scrum-Team für den Erfolg positioniert. Wenn Sie sich das obige Flussdiagramm ansehen, befindet sich der Fokus von Scrum — der taktische Teil — auf der rechten Seite, während der Produktentdeckungsteil — der operative Teil — auf der linken Seite liegt. Es gibt zahlreiche Möglichkeiten, sich mit dem linken Teil des Prozesses zu beschäftigen, zum Beispiel Lean Start-up, Design Thinking, Design Sprint, Lean UX oder Dual-Track Agile, um nur einige zu nennen.

Ein Scrum-Team muss zu jeder Zeit gleichzeitig und kontinuierlich Produktfindung und Produktlieferung (oder Produktentwicklung) betreiben. Diese Notwendigkeit bedeutet jedoch nicht, dass alle Arbeitsaufgaben in das Product Backlog hineingezwängt werden müssen. Im Gegenteil, meiner Erfahrung nach bleiben Scrum-Teams unter ihren Möglichkeiten, wenn sie sich nicht strikt daran halten, zwei verschiedene Artefakte für beide Teile des Prozesses zu pflegen:

1. Es sollte ein transparentes Artefakt geben, in dem Ideen, Hypothesen, Experimente und Ergebnisse festgehalten werden. (Ich bezeichne einen Teil dieses zusätzlichen Artefakts gerne als Anti-Produkt-Backlog, eine dynamische Sammlung von Themen, die ein Scrum-Team nicht weiterverfolgen möchte.)
2. Das zweite Artefakt ist natürlich das Product Backlog. Ein effektives Scrum-Team unternimmt große Anstrengungen, um dieses Artefakt "umsetzungsfähig" zu halten. Ein umsetzbares Product Backlog spiegelt die kontinuierlichen Bemühungen des Scrum-Teams bei der Produktentdeckung im Allgemeinen wider, hier: die Entwicklung einer begründeten Meinung darüber, welche Idee für die Kunden wertvoll sein könnte, sowie die Verfeinerung dieser validierten Hypothesen in geeignete Product Backlog-Einträgen. Zu diesem Zeitpunkt versteht jedes Mitglied des Scrum-Teams, warum das Team diese Möglichkeit vor anderen verfolgt, was die Entwickler bauen sollen, wie sie dies erreichen wollen und wahrscheinlich schon in diesem Stadium, wer daran arbeiten wird. Normalerweise umfasst ein "umsetzungsfähiges" Product Backlog Arbeit für drei bis sechs Sprints. Da der Product Owner die Product Backlog-Elemente nach ihrem Wert ordnet, hat das Scrum-Team auch eine gute Vorstellung davon, wann sie an verschiedenen Aufgaben arbeiten werden.

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 Ausschuss von Stakeholdern priorisiert das Product Backlog. (Die Stärke von Scrum beruht auf der starken Position des Product Owners. Der Product Owner ist die einzige Person, die entscheidet, welche Aufgaben in das Product Backlog aufgenommen werden. Daher entscheidet der Product Owner auch über die Anordnung des Product Backlogs. Nimmt man ihnen diese Befugnis, verwandelt sich Scrum in einen ziemlich effizienten Wasserfall 2.0-Prozess.)
2. Überdimensioniert: Der Product Backlog enthält mehr Einträge, als das Scrum-Team innerhalb von drei bis sechs Sprints liefern kann. (Auf diese Weise erzeugen Product Owner unnötige Arbeit, indem sie Aufgaben und Probleme sammelt, die möglicherweise nie angegangen werden.)
3. Veraltete Einträge: Das Product Backlog enthält Einträge, die seit sechs, acht oder mehr Wochen nicht mehr ansehen wurden. (Das ist typischerweise die Länge von drei bis vier Sprints. Wenn der Product Owner Product-Backlog-Einträge hortet, besteht das Risiko, dass ältere Einträge rasch im Wert verfallen und somit die zuvor investierte Arbeit des Scrum-Teams umsonst war.)
4. 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 Arbeitszeit des Scrum-Teams. Die Verfeinerung der Product Backlog-Einträge ist ein kontinuierlicher Prozess, der nur bis zu dem Punkt fortgesetzt wird, an dem das Scrum-Team diese Einträge in Produkt-Inkremente umwandeln kann.)
5. INVEST? Der Product Owner wendet das INVEST-Prinzip von Bill Wake nicht auf Produktbacklogeinträge an. (Wenn es nicht gelingt, unabhängige, wertvolle und kleine Arbeitsaufgaben zu erstellen, erhöht sich das Risiko, dass die Umsetzung während des Sprints scheitert. Daher ist ein Scrum-Team gut beraten, in eine angemessene Verfeinerung des Product Backlogs zu investieren, um mögliche Probleme zu lösen, bevor sie mit der Arbeit an einzelnen Aufgaben beginnen.)
6. Komponenten-basierte Einträge: Die Product Backlog Elemente werden horizontal nach Komponenten und nicht vertikal nach End-to-End-Anwendermerkmalen aufgeteilt. (Dies kann entweder durch Ihre Organisationsstruktur verursacht werden, ein Effekt, der als Conways Gesetz bezeichnet wird. In diesem Fall sollten Sie diese Störung der Organisationsstruktur überwinden, indem Sie zu interdisziplinären Teams wechseln, um die Lieferfähigkeit des Scrum-Teams zu verbessern. Andernfalls sollte das Scrum-Team in einen Workshop zum Verfassen besserer Product-Backlog-Elemente investieren.)
7. Fehlenden Akzeptanzkriterien: Es gibt Einträge im Product Backlog, die zusätzliche Akzeptanzkriterien benötigen, ohne dass diese aufgelistet werden. (Es ist nicht notwendig, zu Beginn des Verfeinerungszyklus alle Akzeptanzkriterien parat zu haben, obwohl sie die Aufgabe viel leichter verständlich machen würden. Alle Einträge im Product Backlog müssen jedoch schließlich der Definition of Done und ggf. den individuellen Anforderungen auf der Ebene des Arbeitspakets entsprechen. Wenn die Definition of Done Letztere nicht enthält, ergeben sich die nun erforderlichen Akzeptanzkriterien aus dem Verfeinerungsprozess.)
8. 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 Randfall ab, ohne mit den Entwicklern zu kommunizieren. Normalerweise sind drei bis fünf Abnahmekriterien mehr als ausreichend. Wenn Sie der Meinung sind, dass Sie mehr Kriterien benötigen, kann dies ein Hinweis darauf sein, dass der Product-Backlog-Eintrag noch zu groß ist. Sie sollten diesen dann ggf. in kleinere Aufgabenpakete aufteilen.)
9. 100% im Voraus: Das Scrum-Team erstellt im Vorfeld ein Product Backlog, welches das gesamte Projekt oder Produkt abdeckt, da dessen Umfang als begrenzt angesehen wird. (Lassen Sie mich eine Frage stellen: Wie können Sie sicher sein, heute zu wissen, was Sie in sechs Monaten liefern werden, wenn Sie an einem komplexen und adaptiven Problem arbeiten? Ist die Ungewissheit über die Zukunft nicht der Grund, warum Sie Scrum überhaupt einsetzen?)
10. Nicht mehr als ein Titel: Der Product Backlog enthält Einträge, die nur aus einem Titel bestehen. (Das Hinzufügen zahlreicher "Gedächtnisstützen" zum Backlog, wodurch das Signal, welches das Backlog liefern soll, verschleiert wird, beeinträchtigt die Fähigkeit des Scrum-Teams, wertvolle Produkt-Inkremente für die Kunden zu erstellen. Ideen gehören nicht in das Product Backlog; sie sind Teil des anderen Artefakts, des Product-Discovery-Systems.)
11. Keine Experimente: Das Product Backlog enthält wenige bis gar keine Spikes bzw. zeitlich begrenzte Forschungsaufgaben. (Dieser Effekt hängt oft damit zusammen, dass ein Scrum-Team zu viel Zeit damit verbringt, zukünftige Probleme zu diskutieren, anstatt sie im Rahmen eines kontinuierlichen Product-Backlog-Verfeinerungsprozesses mithilfe eines Spikes zu erforschen.)

Product Backlog Anti-Patterns des Product Owner

1. Ideenspeicher: Der Product Owner verwendet das Product Backlog als Verzeichnis für Ideen und Anforderungen. (Ein großes Product Backlog gilt wohl als Zeichen für ein "gutes" Scrum-Team: Sie sind völlig transparent und das ist ein Beweis für Ihre Nützlichkeit für die Organisation. "Vielbeschäftigt" zu sein, ist jedoch nicht gleichbedeutend mit Wert für die Kunden und das Unternehmen schaffen. Das zusätzliche Rauschen, das durch die schiere Anzahl der Einträge entsteht, kann die Erkennung wertvoller Product-Backlog-Einträge beeinträchtigen. Und schließlich kann die Größe des Product Backlogs einen Verdrängungseffekt auf die Stakeholder haben, da sie sich überfordert fühlen. Das mit Ideen aufgeblähte Product Backlog kann die wichtige Kommunikation mit ihnen behindern.)
2. Teilzeit-Product Owner: Der Product Owner arbeitet nicht täglich am Product Backlog. (Das Product Backlog muss die beste Nutzung der Zeit der Entwickler zu jedem beliebigen Zeitpunkt darstellen. Nehmen wir an, eine Aktualisierung des Product Backlogs erfolgt nur gelegentlich, zum Beispiel kurz vor der nächsten Sprintplanung. Aufgrund mangelnder Verfeinerung der Einträge wird dabei wahrscheinlich viel potentieller Wert nicht realisiert. Der Wert des Product Backlogs ergibt sich zu einem großen Teil aus der offenen Diskussion zwischen dem Product Owner und den Entwicklern. In einem guten Scrum-Team stellen die Entwickler den Product Owner ständig in Frage, was den Wert der vorgeschlagenen Product-Backlog-Elemente angeht. Dieser Ansatz der gegenseitigen Kontrolle verringert die Wahrscheinlichkeit, dass der Product Owner einem Confirmation-Bias zum Opfer fällt, und mindert damit das Risiko, dass das Scrum-Team bei der nächsten Sprint-Planung eine falsche Investitionsentscheidung trifft. Wie das Sprichwort schon sagt: Liebe das Problem des Kunden nicht Deine Lösung.)
3. Kopieren & Einfügen-PO: Der Product Owner erstellt Product Backlog-Einträge, indem er die von den Stakeholdern erhaltenen Anforderungsdokumente in kleinere Stücke zerlegt. (Dieses Szenario hat dem Product Owner den Spitznamen "Ticket-Monkey" eingebracht. Denken Sie daran: Das Verfeinern von Product-Backlog-Elementen ist eine Teamaufgabe. Außerdem hilft die Verwendung von Praktiken, wie z. B. Ron Jeffries’ User Story-Vorlage, allen Beteiligten, das Warum, das Was und das Wie zu verstehen. Erinnern Sie sich an Karl Popper: “Always remember that it is impossible to speak in such a way that you cannot be misunderstood.”)
4. Dominanter PO: Der Product Owner erstellt Product Backlog-Elemente, indem er nicht nur das 'Warum', sondern auch das 'Wie' und das 'Was' vorgibt. (Halten Sie sich einfach an den Scrum Guide und seine eingebauten Checks & Balances: Die Entwickler beantworten die Frage nach dem 'Wie', die technische Umsetzung, und das Team und der Product Owner arbeiten gemeinsam an der Frage nach dem 'Was': Welcher Umfang ist notwendig, um den gewünschten Zweck zu erreichen?)
5. User-Story-Autor: Der Product Owner investiert im Vorfeld zu viel Zeit in die Erstellung von Product Backlog-Einträgen, sodass diese zu detailliert sind. (Wenn ein Arbeitspaket "vollständig" aussieht, sehen die Entwickler möglicherweise nicht die Notwendigkeit, sich an der weiteren Verfeinerung zu beteiligen. Auf diese Weise verringert ein "fertig aussehender" Product Backlog-Eintrag den Grad des Engagements des Teams und beeinträchtigt die Schaffung eines gemeinsamen Verständnisses. Das ist übrigens nicht passiert, als wir noch mit Karteikarten gearbeitet haben, da diese nur beschränkt Platz hatten.)
6. "Schaffe ich schon allein” Product Owner: Der Product Owner bezieht weder Stakeholder noch die Fachexperten in den Verfeinerungsprozess ein. (Product Owner, die glauben, entweder allwissend zu sein, oder die die Kommunikation mit Außenstehenden nur über sich laufen lassen, stellen ein Risiko für den Erfolg des Scrum-Teams dar. Fähige Scrum-Teams im Allgemeinen und Product Owner im Besonderen wissen sehr wohl, wann sie sich an andere wenden müssen, um eine Aufgabe besser verstehen zu können.)

Anti-Patterns auf Portfolio- und Roadmap-Ebene

1. Roadmap? Der Product Backlog spiegelt die Roadmap nicht wider. (Das Product Backlog sollte detailliert genug sein, um das aktuelle Produktziel zu erreichen. Meiner Erfahrung nach kann dieses mittlere Planungsziel oft bis zu drei bis vier Sprints in Anspruch nehmen. Jenseits dieses Punktes sollte sich das Product Backlog stattdessen in groben Zügen auf Themen aus der Produkt-Roadmap konzentrieren, die auf das kommende Produktziel hinweisen, aber noch nicht zu konkret sind. Das Realisierungsrisiko dieser Themen ist an diesem Punkt noch zu hoch. In dieser Hinsicht spiegelt das Product Backlog eine "rollierende" Teilmenge der Produkt-Roadmap zu einem bestimmten Zeitpunkt wider.)
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 "fortlaufend", um das Risiko einer Fehlallokation von Arbeit auf veraltete Pläne zu minimieren. Diese Art der "rollierenden Planung" gilt auch für Produkt-Roadmaps, die je nach Branche mindestens alle 6-12 Wochen überarbeitet werden sollten.)
3. Roadmaps bleiben ein Geheimnis: Die Portfolioplanung, der Release-Plan oder die Produkt-Roadmap sind nicht für jeden sichtbar, der an der Erstellung von Produktinkrementen beteiligt ist. (Wenn Sie nicht wissen, wohin Sie gehen wollen, führt Sie jeder Weg dorthin. Die Kenntnis des "großen Ganzen" ist für den Erfolg eines Scrum-Teams entscheidend. Dieses muss allen zugänglich sein, denn Produkterfolg mit Scrum ist ein Mannschaftssport, der von den Ideen, Erkenntnissen und Fähigkeiten aller Teammitglieder und Stakeholder abhängt.)
4. Weltenträume: Die Portfolioplanung, der Release-Plan oder die Produkt-Roadmap werden von denjenigen, die sie liefern sollen, für unerreichbar und nicht glaubwürdig gehalten. (Wenn sich dies im Product Backlog widerspiegelt, ist die Verfeinerung von Arbeitsaufgaben wahrscheinlich eine Verschwendung.)/li>

Anti-Patterns der Entwickler

1. Unterwürfige Entwickler: Die Entwickler befolgen willfährig alle Anweisungen des Product Owners. (Es ist die vornehmste Pflicht eines jeden Teammitglieds, den Product Owner herauszufordern, ob dessen Auswahl von Arbeitsaufgaben die beste Nutzung der Zeit der Entwickler darstellt: Warum sollen wir das tun? Scrum funktioniert nicht, wenn sich nicht jeder an die in das Framework eingebauten Checks & Balances hält. Es ist leicht, sich in "die eigene Lösung" zu verlieben, anstatt sich um das eigentliche Kundenproblem zu kümmern. Wenn die Entwickler einfach alles machen, was der Product Owner "vorschlägt", wird der vom Scrum-Team geschaffene Gesamtwert wahrscheinlich unter seinem Potenzial liegen. Deshalb wollen Sie Missionare in Ihrem Team haben, nicht nur Söldner.)
2. Technische Schulden? Die Entwickler verlangen keine angemessene Zeit, um technische Schulden und Bugs zu beseitigen und den Qualitätsstandard des Produkts zu bewahren bzw. zu verbessern. Stattdessen geben sie sich ganz der Feature-Fabrik hin und liefern eine neue Funktion nach der anderen. (Meine Faustregel lautet, dass die Entwickler bis zu 20 % ihrer Zeit für die Behebung von Fehlern und die Überarbeitung der Codebasis aufwenden sollten. Ein qualitativ hochwertiger Tech-Stack ist die Voraussetzung dafür, dass wir als Scrum-Team unsere nächsten Schritte an die gewonnenen Erkenntnisse und die neuesten Markttrends anpassen können. Technische Exzellenz ist eine Voraussetzung für jede Form von betrieblicher Agilität; die Erhaltung dieses Zustands ist ein kontinuierlicher Prozess, der eine stetige und erhebliche Investition erfordert.)
3. Keine Pufferzeiten: Die Entwickler verlangen vom Product Owner keine 20 % Slack Time bzw. ungeplante Kapazität. (Dieses Problem überschneidet sich mit der Sprintplanung, der Erstellung von Sprint-Zielen und der Fähigkeit des Teams, Prognosen zu erstellen und kann nicht früh genug adressiert werden. Wenn die Kapazität eines Teams immer zu 100 % ausgelastet ist, wird seine Leistung sinken. Jeder wird sich auf die Erledigung seiner Aufgaben konzentrieren. Es bleibt weniger Zeit für die Unterstützung der Teamkollegen oder allgemein für die Zusammenarbeit untereinander. Kleinere Probleme werden nicht mehr zeitnah angegangen. Und letztendlich wird die Einstellung "ich bin beschäftigt" dazu führen, dass nicht mehr alle Teammitglieder verstehen, warum sie das tun, was sie tun.)

Product Backlog Anti-Patterns des Scrum-Teams

1. Wie Team? Der Product Owner bezieht nicht das gesamte Scrum-Team in den Prozess der Verfeinerung des Product Backlogs ein und verlässt sich stattdessen nur auf den "Lead Engineer" und einen Designer. Darüber hinaus sind die Entwickler mit diesem Ansatz einverstanden, da sie so mehr Code schreiben können. (Wenn man versucht, ein komplexes Problem zu lösen, gibt es keine Experten, sondern viele konkurrierende Ideen. Wenn man daher die Anzahl der aktiven Teilnehmer an den Verfeinerungsaktivitäten auf einige wenige Teammitglieder beschränkt, erhöht sich das Risiko, dass man Opfer eines Bestätigungsfehlers bzw. Confirmation Bias wird, da die Meinungsvielfalt unnötig eingeschränkt wird.)
2. Keine Zeit für Refinement: Das Scrum-Team führt nicht genügend Sitzungen zur Verfeinerung des Product Backlogs durch, was zu einem qualitativ minderwertigen Product Backlog führt. (Der Scrum Guide 2017 empfahl ursprünglich, bis zu 10 % der Zeit des Scrum-Teams auf die Verfeinerung des Product Backlogs zu verwenden. Das ist eine gute geschäftliche Entscheidung: Nichts ist teurer als eine schlecht konzipierte Funktion, die wenig oder gar keinen Wert für die Kunden schafft.)
3. Zuviel Refinement: Das Scrum-Team hat zu viele Verfeinerungssitzungen, was zu einem zu detaillierten Product Backlog führt. (Zu viel Verfeinerung ist auch nicht hilfreich. Es gibt einen Zeitpunkt, an dem der Grenzertrag zusätzlicher Verfeinerungsarbeit gleich Null oder wahrscheinlich sogar negativ ist — denken Sie an das Phänomen der Analyse-Paralyse. Die einzige Möglichkeit für ein Scrum-Team zu verstehen, ob die vorherige Validierung der zugrunde liegenden Hypothesen einer neuen Funktionalität korrekt ist, besteht darin, dieses Teil zu bauen und auszuliefern. Es gibt keine Möglichkeit, dies am grünen Tisch herauszufinden, indem man das Thema endlos von allen denkbaren Seiten beleuchtet und diskutiert.)

Fazit

Selbst wenn Sie erfolgreich ermittelt haben, was als Nächstes gebaut werden sollte, bieten Ihr Product Backlog und sein Verfeinerungsprozess wahrscheinlich noch Spielraum für Verbesserungen. Sprechen Sie das Team einfach darauf an und gehen Sie in der nächsten Retrospektive auf mögliche Anti-Patterns im Product Backlog ein. Meiner Erfahrung nach ist dies der einfachste Weg, um die Leistung des Scrum-Teams und damit das Ansehen des Teams bei Stakeholdern und Kunden zu verbessern.

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:

Weitere Blogposts

A Forensic Product Backlog Analysis — Making Your Scrum Work

20 Sprint Planning Anti-Patterns

28+2 Sprint Anti-Patterns

Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team

21 Sprint Retrospektive Anti-Patterns

All Posts on Scrum Anti-Patterns

Download the Scrum Anti-Patterns Guide for free.

✋ Nicht versäumen und mehr über Product Backlog Anti-Patterns erfahren: Werden Sie Mitglied im 11.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.

Der Artikel 27 Product Backlog Anti-Patterns erschien zuerst auf Berlin-Product-People.com.