Product Owner Fehlverhalten — 36 Möglichkeiten, sich als PO zu verbessern

Scrum Anti-Patterns Guide — Berlin Product People

In Kürze: Scrum Product Owner Anti-Pattterns

Wenn Sie als Product Owner arbeiten, könnte Ihnen diese Liste mit einigen der häufigsten Beispielen von Product Owner Fehlverhalten nützlich sein. Wenn Sie einige dieser in Ihrer täglichen Arbeit wiedererkennen, so bitten Sie doch Ihr Scrum-Teams um Unterstützung. Die Liste der Product Owner Anti-Muster ist ein guter Ausgangspunkt für eine Retrospektive.

Product Owner Fehlverhalten — 36 Möglichkeiten, sich als PO zu verbessern – Berlin Product People GmbH

Möchten Sie neue Artikel künftig in Ihrem Posteingang vorfinden? Sie können sich hier für unseren Newsletters ‘Food for Agile Thought’ anmelden und sich 26,000 anderen Abonnenten anschließen.

📅 Nehmen Sie am 25. Hands-on Agile-Meetup am 20. August 2020 teil, um virtuelles Ecocycle Planning mit Qiqochat und Mural zu erkunden.

Die Rolle des Product Owners nach dem Scrum-Guide

“The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” Der vorrangige Weg, dieses Ziel als PO zu erreichen, ist die Handhabung des Product Backlog. Nach dem Scrum Guide umfasst diese Aktivität Folgendes:

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Optimizing the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

Quelle: Scrum Guide 2017.

(Sehen Sie sich die vollständige Liste des Scrum Guide 2017 über das Entwicklungsteam an, indem Sie den Scrum Guide Reordered herunterladen..)

Meiner Erfahrung nach resultieren die häufigsten Product Owner Fehlverhalten aus einer nicht angemessenen Handhabung dieser Product-Backlog-Managementaufgabe.

Cannot see the form?
Please click here

Fehlverhalten im Management des Product Backlogs und dessen Verfeinerung

Die meisten Product Owner Fehlverhalten können Sie im Hinterhof des PO entdecken – im Management des Product Backlogs und dessen Verfeinerung:

  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. 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.)
  7. 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?)
  8. Ü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.)
  9. 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.)
  10. 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.)
  11. 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).
  12. 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.)
  13. Nicht mehr als ein Titel: Der Product Backlog enthält Einträge, die nur aus einem Titel bestehen. (Ein klassisches Product Owner Fehlverhalten: Das Product Backlog als Ablage.)
  14. 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.)
  15. 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.)
  16. 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.)
  17. “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.)
  18. 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).
  19. 📅 Schulungstermine für Professional Scrum Master Training — Berlin Product People GmbH

    Product Owner Fehlverhalten während des Sprint Plannings

    Der zweitwichtigste Bereich auf meiner Liste der Anti-Muster des Product Owners ist die Sprintplanung:

    • Wofür arbeiten wir? Der Product Owner kann das Geschäftsziel des bevorstehenden Sprints nicht mit der allgemeinen Produktvision in Einklang bringen. (Ein ernstzunehmendes Geschäftsziel beantwortet die Frage “Wofür arbeiten wir?” Bis zu einem gewissen Grad ist dies in Folge auch eine Verhandlung zwischen dem Product Owner und dem Entwicklungsteam. Das Geschäftsziel sollte daher fokussiert und messbar sein, da das Sprint-Ziel — auf dem Geschäftsziel basiert — und die Prognose des Entwicklungsteams Hand in Hand gehen.)
    • Kein Geschäftsziel, kein Sprint-Ziel: Der Product Owner schlägt Product Backlog-Einträge vor, die eher einer zufälligen Zusammenstellung von Aufgaben ähneln und daher auch keinen Bezug zueinander haben. Folglich erstellt das Scrum-Team kein Sprint-Ziel. (Wenn dies die normale Art und Weise ist, wie Sie Ihr Sprint Planning abzuschließen, dann haben Sie unter Umständen die Nützlichkeit von Scrum als Produktentwicklungs-Framework bereits überlebt. Je nach dem Reifegrad Ihres Produkts kann sich Kanban als bessere Lösung erweisen. Andernfalls kann die Zufälligkeit einen schwachen Product Owner signalisieren, der zu sehr auf die Stakeholder hört, anstatt das Product Backlog aus Sicht der Nützlichkeit für die Kunden entsprechend zu ordnen.)
    • Unvollendete Geschäfte: Unvollendete Aufgaben aus dem letzten Sprint werden ohne Diskussion in den neuen Sprint übernommen. (Es kann gute Gründe dafür geben, z.B. weil sich der Wert einer Aufgabe nicht geändert hat. Es sollte jedoch kein Automatismus sein, denken Sie an den Sunk Cost-Trugschluss.)
    • Änderungen in letzter Minute: Der Product Owner versucht, in letzter Minute unfertige Product Backlog-Einträge im Sprint unterzubringen. (Im Prinzip ist es das Vorrecht des Product Owners, solche Änderungen vorzunehmen, um sicherzustellen, dass das Entwicklungsteam zu jedem Zeitpunkt an den wertvollsten Aufgaben arbeitet. Wenn das Scrum-Team jedoch ansonsten regelmäßig Verfeinerungen des Product Backlogs durchführt, sollten solche Vorkommnisse eine seltene Ausnahme sein. Wenn diese häufiger vorkommen, deutet dies darauf hin, dass der Product Owner Hilfe bei der Erstellung des Product Backlogs und in der Teamkommunikation benötigt. Oder der Product Owner braucht Unterstützung, um öfter “Nein” zu den Interessenvertretern zu sagen.)
    • Output-Fokussierung: Der Product Owner drängt das Entwicklungsteam, mehr Aufgaben zu übernehmen, als es realistischerweise bewältigen kann. Wahrscheinlich bezieht sich der Product Owner dabei auf frühere Teammetriken wie die Velocity, um seinen Wunsch zu unterstützen. (Dies ist auch ein sicherer Weg, um eine Feature Factory zu werden, und verdient die Aufmerksamkeit des Scrum Masters: Es ist eine Verletzung des Vorrechts des Entwicklungsteams, die Product Backlog-Einträge für das Sprint Backlog auszuwählen und missachtet die Scrum-Werte).
    • Fehlende Vorbereitung: Der Product Owner bereitet das Product Backlog für Auswahl nützlicher Product Backlog-Einträge durch das Entwicklungsteam nicht vor. (Das Product Backlog muss zu jedem Zeitpunkt die bestmögliche Nutzung der Arbeit des Entwicklungsteams aus der Perspektive des Kundennutzens darstellen. Mit anderen Worten, das Product Backlog Ihres Scrum-Teams muss rund um die Uhr “actionable” sein. Nach meinen Maßstäben bedeutet dies, dass Sie jederzeit in der Lage sein müssen, ein sinnvolles Sprint Planning durchzuführen. Es reicht als PO nicht aus, eine Stunde vor Beginn des Sprint Plannings kurz mal eben einige Product Backlog-Einträge vorzubereiten).

    Fehlverhalten im Rahmen des Sprints

    Ein weiterer Bereich für Product Owner Fehlverhalten ist der Sprint an sich:

    • Der abwesende Product Owner: Der Product Owner ist den größten Teil des Sprints abwesend und steht dem Entwicklungsteam nicht für Fragen zur Verfügung. (Da das Sprint-Backlog sich herausbildet und ggf. neue Arbeiten als notwendig für das Erreichen des Sprint-Ziels identifiziert werden, könnte diese Haltung das Entwicklungsteam im Dunkeln tappen lassen und die Erreichung des Sprint-Ziels gefährden).
    • Der klammernde PO: Der Product Owner kann von Product Backlog-Einträgen nicht loslassen, sobald dieses Teil des Sprint Backlog werden. Der Product Owner erhöht beispielsweise den Umfang eines Eintrages oder ändert die Akzeptanzkriterien, nachdem das Team die Aufgabe in das Sprint Backlog aufgenommen hat. (Es gibt eine klare Linie: Bevor ein Product-Backlog-Eintrag zu einem Teil des Sprint Backlog wird, ist der Product Owner verantwortlich. Sobald der Product Backlog-Eintrag jedoch das Sprint Backlog übergeht, wird das Entwicklungsteam verantwortlich. Wenn Änderungen während des Sprints erforderlich werden, entscheidet das Team gemeinsam, wie es damit umgeht).
    • Der unflexible Product Owner: Der Produkteigentümer ist nicht flexibel bei der Anpassung der Akzeptanzkriterien. (Wenn sich bei der Arbeit an einer Aufgabe herausstellt, dass die vereinbarten Akzeptanzkriterien nicht mehr erreichbar sind, muss sich das Scrum-Team an die neue Realität anpassen. Die blinde Befolgung des ursprünglichen Plans verstößt gegen zentrale Scrum-Prinzipien).
    • Der verzögernde PO: Der Product Owner akzeptiert keine Arbeiten aus dem Sprint-Backlog, sobald diese beendet sind. Stattdessen wartet er oder sie bis zum Ende des Sprints. (Der Product Owner sollte Aufgaben, die die Akzeptanzkriterien erfüllen, sofort überprüfen. Andernfalls schafft der Product Owner eine künstliche Queue innerhalb des Sprints, welche die Cycle-Time von Product Backlog-Einträgen unnötig erhöht. Diese Gewohnheit gefährdet auch das Erreichen des Sprint-Ziels).
    • Missbrauch des Sprint-Abbruchs: Der Product Owner bricht Sprints ab, um dem Team seinen Willen aufzuzwingen. (Es ist das Vorrecht des Product Owners, Sprints abzubrechen. Der Product Owner sollte dies jedoch nicht ohne einen ernsthaften Grund tun. Auch sollte dies niemals ohne vorherige Rücksprache mit dem Entwicklungsteam geschehen. Ggf. hat das Team eine Idee, wie der Sprint gerettet werden kann. Des Weiteren weist der Missbrauch des Abbruchprivilegs auch auf ein ernstes Problem der Zusammenarbeit des Teams hin).
    • Kein Sprint-Abbruch: Der Product Owner bricht einen Sprint, dessen Sprint-Ziel nicht mehr erreicht werden kann, nicht ab. (Wenn der Product Owner eine lohnende Aufgabe für den Sprint identifiziert hat, z. B. die Integration einer neuen Zahlungsmethode, und das Management diese Zahlungsmethode dann mitten im Sprint aufgibt, wäre es eine Verschwendung, weiter an dem Sprint-Ziel zu arbeiten. In diesem Fall sollte der Product Owner in Erwägung ziehen, den Sprint abzubrechen).

    Fehlverhalten des PO im Daily Scrum

    Im Vergleich zu anderen Scrum-Events ist das Daily Scrum bemerkenswert widerstandsfähig gegenüber Product Owner Fehlverhalten:

    • Planungsmeeting: Der Product Owner nutzt das Daily Scrum, um neue Anforderungen zu diskutieren, User Stories zu verfeinern oder eine Art (Sprint)-Planning durchzuführen.
    • Gesprächiger PO: Der Product Owner nimmt aktiv am Daily Scrum teil. (Product Owner und Stakeholder sollten zuhören, aber die Mitglieder des Entwicklungsteams während ihrer Inspektion nicht ablenken.)
    • Mehrarbeit: Der Product Owner oder auch andere Stakeholder versuchen, während des Daily Scrum neue Arbeiten in den aktuellen Sprint einzubringen. (Dieses Verhalten kann für Fehler der höchsten Prioritätsstufe akzeptabel sein, obwohl das Entwicklungsteam diese vor dem Daily Scrum in der Regel bereits kennen sollte. Andernfalls liegt die Zusammensetzung des Sprint Backlogs in der alleinigen Verantwortung des Entwicklungsteams.)

    Das Sprint Review und Product Owner Fehlverhalten

    Schließlich gibt es noch das Sprint-Review. Obwohl dies eine hervorragende Gelegenheit für den Product Owner ist, die Zusammenarbeit mit den Interessengruppen und dem Entwicklungsteam zu verbessern und gemeinsam herauszufinden, in welche Richtung das Produkt als Nächstes gehen soll, verstehen einige Product Owner den Sinn und Zweck des Sprintreviews nicht:

    • Eigennütziger Product Owner: Der Product Owner präsentiert den Stakeholdern “seine” Leistungen. (Erinnern Sie sich an das alte Sprichwort: There is no “I” in “team?”)
    • “Abnahme” durch den Product Owner : Der Product Owner nutzt den Sprint Review, um Aufgaben bzw. Produkt Backlog-Einträge “abzunehmen”. (Eine Abstimmung — hat das Entwicklungsteam die erforderliche Funktionalität geliefert? — ist nützlich, aber sollte vom Sprint Review abgekoppelt werden. Der Product Owner sollte sich mit dem Entwicklungsteam abstimmen, sobald Aufgaben die definierten Akzeptanzkriterien erfüllen.)
    • Unnahbarer Product Owner: Der Product Owner akzeptiert kein Feedback von Stakeholdern oder dem Entwicklungsteam. (Ein solches Verhalten verstößt gegen den Hauptzweck des Sprint Review Events.)

    Die Youtube-Playlist des Webinars über PO Anti-Muster ist verfügbar

    Die Videos des Webinars sind jetzt verfügbar:

    Anmerkung: Wenn der Browser die Wiedergabeliste nicht automatisch abspielt, klicken Sie hier, um sich die Wiedergabe des Webinars Product Owner Anti-Patterns direkt auf Youtube zu sehen.

    Fazit

    Zugegebenermaßen ist die Rolle des Product Owners die anspruchsvollste Scrum-Rolle, und je höher die Erwartungen sind, desto leichter ist es, sie zu enttäuschen. Dennoch gilt das Konzept der kontinuierlichen Verbesserung auch für die Rolle des Product Owners. Die obige Liste von Product Owner Fehlverhalten kann ein Ausgangspunkt hierfür sein.

    Welche Antimuster des Product Owners haben Sie beobachtet, die in der Liste fehlen? Bitte teilen Sie uns diese in den Kommentaren mit.

    ✋ Nicht versäumen: Lernen Sie mehr über Product Owner Fehlverhalten im 7.900-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.

    Nicht versäumen: Lernen Sie mehr über die toxische Teamkultur im 7.900-köpfigen

    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.

    PO Fehlverhalten — Empfohlene Lektüre

    28 Product Backlog and Refinement Anti-Patterns

    20 Sprint Planning Anti-Patterns

    Liberating Structures for Scrum (3): The Product Backlog

    Download the ’Scrum Anti-Patterns Guide’ for Free

    Tags: Product Owner, Scrum Anti-Patterns, Scrum Fehlverhalten

Leave a reply

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