Wert messen
Wie der PO Fortschritt & Nutzen prüft
1
Nutzung— Wird das Produkt wirklich genutzt?
2
Zufriedenheit— Feedback von Kunden & Nutzern
3
Auslieferung— Regelmäßig funktionierende Increments
4
Geschäftsziel— Beitrag zu Umsatz & Strategie
Übungsfragen zu diesem Modell
✍️ OffenErklären Sie, was es für einen Product Owner bedeutet, "Wert zu maximieren", und warum mehr Output nicht automatisch mehr Wert ist.
Musterantwort: Wert maximieren heißt, dass das Produkt möglichst großen Nutzen für Kunden, Nutzer und Organisation stiftet – gemessen an Outcomes (Nutzung, Zufriedenheit, Geschäftsziele), nicht an Output-Menge. Mehr Features (Output) können Wert sogar mindern (Komplexität, ungenutzte Funktionen). Der PO priorisiert deshalb nach erwartetem Wert/Risiko und misst empirisch, ob der Wert tatsächlich eintritt.
Bewertet werden: Wert = Nutzen/Outcome (nicht Output-Menge) + Begründung, warum mehr Features ≠ mehr Wert + empirisches Messen.
☝️ SingleEin Stakeholder verlangt eine verbindliche Zusage, welche Funktionen in sechs Monaten fertig sind. Wie antwortet ein Product Owner angemessen?
❌Er sagt den vollständigen Umfang verbindlich zu
❌Er lehnt jede Aussage zur Zukunft ab
❌Er verweist den Stakeholder an die Developers
✅Er gibt eine Prognose mit erkennbarer Unsicherheit auf Basis bisheriger Lieferdaten und erklärt, dass sie mit jedem Sprint aktualisiert wird
Prognosen sind möglich und nötig, aber sie sind Wahrscheinlichkeitsaussagen. Als Zusage verkauft, werden sie später zwangsläufig gebrochen.
✌️ MultiWelche Kennzahlen eignen sich, um den Erfolg einer neu ausgelieferten Funktion zu beurteilen? (Mehrere richtig)
❌Die Anzahl der Story Points, die für die Funktion aufgewendet wurden.
✅Die Entwicklung von Supportanfragen und Fehlermeldungen im betroffenen Bereich.
✅Der Anteil der Zielgruppe, der die Funktion tatsächlich nutzt.
✅Die Veränderung der Kennzahl, die die Funktion beeinflussen sollte.
Story Points messen Aufwand, nicht Wirkung. Der entscheidende Schritt ist, die erwartete Wirkung vor der Auslieferung zu benennen – sonst fehlt der Maßstab, an dem sich das Ergebnis messen ließe.
☝️ SingleEin Stakeholder übergeht den Product Owner und beauftragt Developers direkt. Wie reagiert der Product Owner angemessen?
❌Er eskaliert sofort an die Geschäftsführung
✅Er sucht das Gespräch, klärt die Verantwortlichkeit für die Reihenfolge und sorgt dafür, dass der Bedarf über das Product Backlog läuft – ohne den Stakeholder abzuweisen
❌Er verbietet den Developers jeden Kontakt zu Stakeholdern
❌Er nimmt den Auftrag hin, um den Konflikt zu vermeiden
Der Bedarf ist meist berechtigt, nur der Weg ist falsch. Wichtig ist, den Weg zu korrigieren, ohne das Anliegen zu entwerten – sonst sucht der Stakeholder sich beim nächsten Mal einen noch verdeckteren Kanal.
☝️ SingleEin Stakeholder mit großem Einfluss zeigt bislang wenig Interesse am Produkt. Welche Strategie ist angemessen?
✅Ihn mit knapper, gezielter Information versorgen und bei relevanten Entscheidungen einbeziehen, damit kein spätes Erwachen entsteht
❌Ihn vorerst nicht informieren, solange kein Interesse besteht
❌Ihn ausschließlich über den allgemeinen Newsletter erreichen
❌Ihn in alle Detailabstimmungen einladen
Das Risiko dieser Gruppe ist der plötzliche Interessenzuwachs: Wird ein mächtiger Stakeholder spät aufmerksam und findet etwas vor, das ihm missfällt, wirkt sein Einfluss sofort in voller Höhe.