Scrum Product Owner: Agile Projekte besser steuern (PSPO 1)

In diesem Video werden kurz und knapp die Kerninhalte von Scrum wiederholt, um eine gemeinsame Grundlage für den restlichen Kurs zu schaffen.

Eine detaillierte Auseinandersetzung mit Scrum und agilen Prozessen findest Du in meinem "Scrum und Agile Meisterkurs"

Hier besprechen wir die Kernaufgaben des Product Owners gemäß Scrum Guide

Wir blicken über die Informationen des Scrum Guides hinaus und fragen uns, mit welchen Aufgaben der Product Owner im Alltag konfrontiert wird.

Hierbei lernst Du, wie facettenreich und komplex das Aufgabenspektrum tatsächlich ist.

Das Product Backlog ist eines der 3 Artefakte in Scrum und hat für den Product Owner eine besondere Bedeutung. Wir fassen hier die wichtigsten Aspekte noch einmal kurz zusammen

Mit dem Update des Scrum Guides im November 2020 wurde das Product Goal neu eingeführt.

Eine kurze Erläuterung findest Du in diesem Video

Auch als Product Owner stehst Du nicht völlig allein. Lerne hier, welche Unterstützung Du vom Scrum Master einfordern kannst und solltest.

Kurze Sprints und Iterationen erfordern einen Fokus auf jene Eigenschaften, die "echten Mehrwert" bringen.

Das Konzept des "minimal viable product" zeigt Dir, worauf bei der Umsetzung von Anforderungen zu achten ist, um einen Erkenntnisgewinn zu erzielen

Anforderungen werden bei Scrum üblicherweise als "User Stories" bezeichnet. Dies zeigt aber ein vereinfachtes Bild. Wir wollen uns in dieser Lektion kurz mit den unterschiedlichen "Klassen" von Anforderungen befassen, um die Unterschiede und deren Bedeutung für unser Produkt besser zu verstehen

In dieser Lektion lernst Du konkret, wie Epics und User Stories voneinander unterschieden werden können und welche Merkmale die jeweiligen Anforderungen ausmachen

Wir vertiefen unsere Diskussion über Epics und User Stories und schauen uns an, wie sich diese in den Sprints verhalten.

Zudem lernst Du Tipps und Tricks, wie Du dafür sorgen kannst, dass mehr User Stories im Sprint auch tatsächlich abgeschlossen werden

Der Schlüssel für gute Anforderungen ist Kommunikation, das zeigt dieser kleine Witz sehr deutlich auf

Lerne hier, wie Du User Stories schreiben solltest und was es mit der INVEST-Regel auf sich hat

Hier erhältst Du eine Vorlage für die Erfassung von User Stories. Diese Vorlage soll Dir ganz konkret helfen, wichtige Aspekte einer Anforderung aufzugreifen und die richtigen Fragen für die Umsetzung zu stellen

Übung macht den Meister. User Stories zu schreiben braucht Zeit und Erfahrung.

Nimm´ Dir meine Ratschläge u.a. zu Schätzungen, technischen Abhängigkeiten und Schnittstellen zu  herzen und lasse Dich nicht von ersten Rückschlägen entmutigen!

Die Definition of Ready ist eine Checkliste mit Merkmalen, die Anforderungen erfüllen sollten, bevor eine Umsetzung startet.

Die Definition of Ready hilft elementare Fragen im Vorfeld der Umsetzung zu klären und kann helfen, eine deutlich effektivere Umsetzung von Anforderungen im Sprint zu erreichen

Die Definition of Done ist eine Checkliste von Merkmalen, welche Anforderungen erfüllen müssen, bevor diese als abgeschlossen gelten.

Die Definition of Ready gewährleistet eine hohe Qualität und enthält oftmals nicht-funktionale Anforderungen und Unternehmensvorgaben

Hier werden die Inhalte des letzten Kapitels kurz und knapp zusammengefasst.

Viel zu oft erlebe ich Product Owner, die Story Points (Aufwand / Komplexität) für Anforderungen schätzen. In diesem Video klären wir, warum dies die Aufgabe des Entwicklungsteams ist und warum sich der Product Owner aus Aufwandsschätzungen unbedingt heraushalten sollte.

Keep it simple! Agile Projekte müssen mit Unsicherheit im Planungsprozess klarkommen. Diese Unsicherheit sollte aber nicht als Schwäche ausgelegt werden, sondern als eine der stärken agiler Vorgehensweisen. Hier klären wir, warum es zu Unsicherheit kommt und wie wir damit umgehen sollten.

Häufig gilt das Sprint Review als jenes Event in dem das Entwicklungsteam im Vordergrund steht. Hierbei wird oft vergessen, dass es um viel mehr als nur die Vorstellung der Ergebnisse des letzten Sprints geht.

Wir blicken hier auf die konkreten Aufgaben des Product Owners im Sprint Review und dessen Bedeutung für die Vorbereitung des nächsten Sprints und/oder Releases.

Burndown Charts sind eine tolle Möglichkeit um den Stakeholdern einen Ausblick auf kommende Releases zu geben. Aber sollten wir hier als Product Owner wirklich alle Informationen mit den Stakeholdern teilen? Lerne hier, wie Du Burndown Charts nutzen kannst und welche Details vielleicht besser zurückgehalten werden, um unnötige und zwecklose Diskussionen zu vermeiden.

Wir ziehen ein kurzes Zwischenfazit zur Planung und halten die wichtigsten Punkte in einem prägnanten One-Pager fest.

Der Fokus auf Qualität hört sich wie ein Selbstverständnis an und doch wird es in vielen Projekten vernachlässigt, wenn der Druck auf das Scrum Team erstmal zu nimmt und Erwartungen steigen.

Lerne hier, welche Konsequenzen entstehen, wenn wir diesen Aspekt nicht von Anfang an beachten und damit sukzessive mehr technische Schulden aufbauen.

Technische Schulden gehören dem Entwicklungsteam!

Korrekt, aber sollten wir als Product Owner deshalb den harten Hund spielen und das Entwicklungsteam im Regen stehen lassen?

Wohl kaum!

Lerne hier, welche Maßnahmen das Scrum Team zur Vermeidung von technischen Schulden ergreifen kann.

Mist! Unsere Maßnahmen zur Vermeidung von technischen Schulden haben nicht gewirkt. Was nun?

Lerne hier, wie Du reagieren kannst, wenn Du in technischen Schulden zu ertrinken drohst und immer mehr Kapazität deines Entwicklungsteams für "Korrekturen" verloren geht.

Hier erhältst Du 9 Tipps für die Releaseplanung, die wir auch in einem One-Pager kurz und knapp zusammenfassen.

Die Produkt Vision bildet den roten Faden für unsere Produktentwicklung und schafft ein gemeinsames Ziel.

Eine klar kommunizierte Vision befähigt das Scrum Team über den Tellerrand einzelner Anforderungen hinauszublicken und eigene Ideen und Vorschläge in den Entwicklungsprozess mit einzubringen, aber...wie kommen wir überhaupt zu einer "guten" Produkt Vision?

Design Thinking füllt Bücher und ganze Kurse. Hier verschaffen wir uns einen Überblick über die wichtigsten Prozessschritte und Abläufe, als eine Option zur Entwicklung unserer Produkt Vision.

Der Einsatz von "Personas" ist eine tolle Möglichkeit ein besseres Verständnis für unseren Kunden zu entwickeln. Personas lassen sich zudem gut mit dem Design Thinking Prozess kombinieren und verschaffen einem sonst so anonymen Kunden etwas mehr "Persönlichkeit"

Eine Produktvision sollte geteilt werden, um das volle Potential auszuschöpfen.

Lerne hier das Product Vision Board kennen, welches schon bald in deinem Scrum Teamraum hängen sollte!

Diese Lektion enthält auch ein entsprechendes Template

Viel zu selten nehmen wir uns Zeit eine Beziehung zwischen unseren Tätigkeiten und unseren Zielen herzustellen. Wir geben uns mit einfachen Antworten zufrieden und verfallen oft in blinden Aktionismus, der zwar viel Papier erzeugt, aber keinen Mehrwert schafft.

Lerne hier einen strukturierten und systematischen Ansatz kennen, der Dir bei der Priorisierung und Auswahl von Maßnahmen hilft, und eine Beziehung zwischen Ziel und Maßnahme herstellt.

Wer, oder was ist eigentlich dieser Nutzen?

Ein Begriff der auch hier im Kurs bereits unzählige Male verwendet wurde, und für den doch jeder ein etwas anderes Verständnis entwickelt hat.

Ist Nutzen immer gleich, oder gibt es verschiedene Perspektiven Nutzen zu betrachten... und.warum ist eine Abgrenzung und ein gemeinsames Verständnis im Projekt überhaupt wichtig?

Eine Betrachtung von Nutzen, ohne den Kunden ist kaum möglich. Aber was schätzt "der Kunde" eigentlich an Produkten?

Lerne hier, welche Erkenntnisse dazu vorliegen und wie Dir das bei einer zielgerichteten Produktentwicklung helfen kann!

Hier werden die Inhalte des letzten Kapitels kurz und knapp zusammengefasst

In dieser Lektion erhältst Du 5 Tipps zur Maximierung des Nutzens in deinem Projekt

Das Kano Modell ist eine großartige Möglichkeit wichtige Features für unser Produkt zu identifizieren. Lerne hier zwischen den unterschiedlichen Merkmalen zu unterscheiden und deren Bedeutung zu verstehen

Im zweiten Teil der Betrachtung des Kano Modells gehen wir auf die systematische Kundenbefragung ein. Hier erhältst Du auch ein Template mit einem Fragebogen inkl. automatischer Auswertung der komplexen Bewertungsmatrix.

Verzögerungskosten sind in einem Projekt völlig normal, werden aber leider oft nicht bewusst für eine Priorisierung betrachtet.

Lerne hier unterschiedliche Entwicklungsverläufe von Verzögerungskosten (Cost of Delay) kennen und in welcher Form diese in unserem Scrum Projekt auftreten könnten

Nach dem die Grundlagen der Verzögerungskosten verstanden sind, erarbeiten wir uns nun eine "Abarbeitungsstrategie" auf Basis des "Weighted Shortest Job First".

Lerne diesen zu berechnen und für deine Priorisierung zu nutzen!

Achtung: Kleiner Fehler in der Berechnung. Korrektes Ergebnis: x=39 [13*3] und y=63 [(13+8)*3]

MoSCoW ist vermutlich die einfachte Art Anforderungen zu priorisieren. Genau deshalb finde ich dieses Modell so interessant und gut anwendbar

Für die Analytiker befassen wir uns hier kurz mit der Kosten-Nutzen Matrix zur Priorisierung von Anforderungen

Für die Analytiker befassen wir uns hier kurz mit der Risiko-Nutzen Matrix zur Priorisierung von Anforderungen

Das Product Backlog Management gehört zu den zentralen Aufgaben des Product Owners. Ein schlechtes Product Backlog Management hat maßgebliche Auswirkungen auf unseren gesamten Entwicklungsprozess.

Lerne hier die Ziele des Product Backlog Managements kennen und welche Warnzeichen es für ein unzureichendes Product Backlog Management gibt, damit Du frühzeitig auf mögliche Probleme reagieren kannst!

Hier gebe ich Dir 9 konkrete Tipps zum Refinement und der Vorbereitung des nächsten Sprint Plannings

Sollte das Entwicklungsteam von den Stakeholdern abgeschirmt werden, um die Einflussnahme von außen im Sprint zu reduzieren, oder sollten wir eine direkte Kommunikation zwischen den Parteien ermöglichen?

Lerne hier, was Du als Product Owner in der Kommunikation zwischen Entwicklungsteam und Stakeholder zulassen kannst, und welche Grenzen Du ziehen solltest.

Nicht alle Stakeholder sind für die Produktentwicklung gleich wichtig.

Lerne hier, wie Du Stakeholder besser einschätzen kannst und dein Stakeholder-Management optimierst und somit Zeit sparst. Hierzu nutzen wir tatsächlich ein Instrument aus dem klassischen Projektmanagement. Die Stakeholder-Analyse

In dieser Lektion teile ich 8 konkrete Tipps zum Stakeholder-Management mit Dir!