Wert messen [Praxis]

13 Übungsfragen mit Lösung und Erklärung.

☝️ SingleEin Produkt liefert regelmäßig Features aus, aber die Nutzungszahlen sinken. Wie sollte der Product Owner reagieren?
❌Die Nutzungszahlen ignorieren, Output zählt
❌Einfach mehr Features liefern lassen
❌Die Developers zu schnellerer Arbeit drängen
✅Den tatsächlichen Wert hinterfragen und das Backlog auf nutzenstiftende Items ausrichten
Sinkende Nutzung trotz Auslieferung signalisiert fehlenden Wert. Der PO richtet das Backlog empirisch auf echten Nutzen aus – Output (mehr Features) ist nicht gleich Outcome (Wert).
☝️ SingleWelche vier Wertbereiche unterscheidet Evidence-Based Management (EBM)?
❌Vision, Strategie, Roadmap und Backlog
❌Umsatz, Kosten, Qualität und Termintreü
✅Aktüller Wert, unrealisierter Wert, Time-to-Market und Innovationsfähigkeit
❌Kundenzufriedenheit, Velocity, Fehlerrate und Auslastung
EBM betrachtet den heutigen Wert, das ungenutzte Potenzial, die Fähigkeit schnell zu liefern und die Fähigkeit zu innovieren.
☝️ SingleEin Produkt erzielt hohe Umsätze, aber neue Funktionen brauchen von der Idee bis zur Auslieferung im Schnitt neun Monate. Welcher EBM-Wertbereich ist am schwächsten?
❌Unrealisierter Wert
❌Innovationsfähigkeit
✅Time-to-Market
❌Aktüller Wert
Hohe Umsätze zeigen guten aktüllen Wert. Die lange Durchlaufzeit ist ein klares Time-to-Market-Problem und begrenzt die Lernfähigkeit.
☝️ SingleWas beschreibt der EBM-Wertbereich unrealisierter Wert?
❌Die technische Schuld des Produkts
❌Den Umsatz des laufenden Geschäftsjahres
❌Die Summe aller nicht umgesetzten Backlog-Einträge
✅Den zusätzlichen Wert, der erschlossen werden könnte, wenn die Bedürfnisse aller potenziellen Nutzer erfüllt würden
Unrealisierter Wert ist die Lücke zwischen heutigem Zustand und dem, was möglich wäre. Er begründet, warum sich Weiterinvestition lohnt.
☝️ SingleWarum ist die Zahl gelieferter Funktionen kein guter Wertmaßstab?
❌Weil Funktionen unterschiedlich groß sind
❌Weil Funktionen sich nicht zählen lassen
❌Weil der Scrum Guide das Zählen verbietet
✅Weil Wert erst durch die Nutzung entsteht und ein großer Teil ausgelieferter Funktionen kaum genutzt wird
Output ist nicht Outcome. Ein Product Owner steuert nach Wirkung beim Nutzer, nicht nach Liefermenge.
☝️ SingleWie sollte ein Product Owner den Erfolg einer neu ausgelieferten Funktion prüfen?
❌Anhand der Einhaltung des geplanten Liefertermins
✅Anhand vorab festgelegter Wirkungsannahmen, die nach der Auslieferung an echten Nutzungsdaten überprüft werden
❌Anhand der Zufriedenheit des Entwicklungsteams
❌Anhand der aufgewendeten Story Points
Ohne vorher formulierte Erwartung lässt sich hinterher jedes Ergebnis als Erfolg deuten. Nur so wird der empirische Regelkreis auf Produktebene geschlossen.
✍️ OffenErklären Sie den Unterschied zwischen Output und Outcome und warum diese Unterscheidung für einen Product Owner zentral ist.
Musterantwort: Output ist das, was geliefert wurde, also Funktionen, Increments oder Releases. Outcome ist die Veränderung, die dadurch beim Nutzer oder im Geschäft eintritt, etwa dass eine Aufgabe schneller erledigt wird, weniger Supportanfragen entstehen oder mehr Nutzer einen Prozess abschließen. Die Unterscheidung ist zentral, weil Output leicht zu messen und leicht zu steigern ist, ohne dass Wert entsteht: Ein Team kann viele Funktionen liefern, die kaum genutzt werden. Ein Product Owner, der nach Output steuert, optimiert Beschäftigung; wer nach Outcome steuert, optimiert Wirkung und kann Dinge auch bewusst weglassen. Praktisch heißt das, vor der Umsetzung eine überprüfbare Wirkungsannahme zu formulieren, nach der Auslieferung an echten Nutzungsdaten zu prüfen und das Product Backlog daraufhin anzupassen. Damit schließt sich der empirische Regelkreis auf Produktebene, so wie Inspektion und Adaption ihn auf Sprintebene schließen.
Bewertet werden: klare Definition beider Begriffe + Beispiel + Begründung warum Output-Steuerung in die Irre führt + praktische Konsequenz (Wirkungsannahme vorab, Überprüfung an Daten, Backlog anpassen) + Bezug zur Empirie.
☝️ SingleWas misst die Kennzahl "Time-to-Market" im Sinne von Evidence-Based Management?
❌Die Dauer eines einzelnen Sprints
❌Die Anzahl der Sprints bis zum Erreichen des Product Goal
❌Den Umsatz pro ausgelieferter Funktion
✅Die Fähigkeit der Organisation, neue Fähigkeiten schnell an Nutzer auszuliefern
Time-to-Market ist der Hebel für alle anderen Wertbereiche: Je schneller ausgeliefert wird, desto schneller kommt Feedback zurück und desto günstiger wird jeder Irrtum.
☝️ SingleWas misst der Net Promoter Score (NPS)?
✅Die Bereitschaft von Kunden, das Produkt weiterzuempfehlen, ermittelt über eine Skalenfrage und die Differenz von Befürwortern und Kritikern
❌Die Anzahl aktiver Nutzer pro Monat
❌Den durchschnittlichen Umsatz pro Nutzer
❌Den Anteil fertiggestellter Backlog-Einträge
Der NPS ist eine Stimmungs-, keine Verhaltensmessung und als Einzelkennzahl mit Vorsicht zu genießen. In Kombination mit tatsächlichen Nutzungsdaten wird er aussagekräftiger.
✌️ 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.
✍️ OffenEin Produkt liefert seit einem Jahr regelmäßig neue Funktionen aus, die Nutzungszahlen stagnieren jedoch. Analysieren Sie mögliche Ursachen und beschreiben Sie Ihr Vorgehen als Product Owner.
Musterantwort: Die Konstellation deutet darauf hin, dass Output erzeugt, aber kein Outcome erreicht wird. Mögliche Ursachen liegen auf mehreren Ebenen. Erstens könnten die gelieferten Funktionen an den tatsächlichen Bedürfnissen vorbeigehen, weil die Priorisierung auf Stakeholder-Wünschen statt auf Nutzerbeobachtung beruht. Zweitens könnten die Funktionen zwar passen, aber unbekannt oder schwer auffindbar sein, was eher ein Einführungs- als ein Entwicklungsproblem wäre. Drittens könnten grundlegende Probleme mit Bedienbarkeit, Geschwindigkeit oder Verlässlichkeit den Nutzen jeder zusätzlichen Funktion überlagern. Viertens könnte der Markt oder die Zielgruppe falsch eingeschätzt sein. Mein Vorgehen würde damit beginnen, überhaupt eine belastbare Datengrundlage herzustellen: Nutzungsdaten je Funktion, Abbruchpunkte in den zentralen Abläufen, Supportanfragen und, ergänzend, direkte Gespräche mit Nutzern. Aus der Kombination von Zahlen und Gesprächen lässt sich meist eingrenzen, auf welcher der genannten Ebenen das Problem liegt. Anschließend würde ich die Arbeitsweise anpassen, indem für künftige Einträge vorab eine erwartete Wirkung mit Messgröße formuliert wird und nach der Auslieferung geprüft wird, ob sie eingetreten ist. Ebenso würde ich Kapazität dafür reservieren, wenig genutzte Funktionen zu verbessern oder zu entfernen, statt ausschließlich Neues zu bauen. Gegenüber den Stakeholdern würde ich die Diskussion bewusst von der Liefermenge auf die Wirkung verschieben und dafür das Sprint Review nutzen.
✍️ OffenEin Produkt liefert seit einem Jahr regelmäßig neue Funktionen aus, die Nutzungszahlen stagnieren. Analysieren Sie mögliche Ursachen und beschreiben Sie Ihr Vorgehen.
Musterantwort: Die Konstellation deutet darauf hin, dass Output erzeugt, aber kein Outcome erreicht wird. Mögliche Ursachen liegen auf mehreren Ebenen. Erstens könnten die gelieferten Funktionen an den tatsächlichen Bedürfnissen vorbeigehen, weil die Priorisierung auf Stakeholder-Wünschen statt auf Nutzerbeobachtung beruht. Zweitens könnten die Funktionen passen, aber unbekannt oder schwer auffindbar sein, was ein Einführungs- und kein Entwicklungsproblem wäre. Drittens könnten grundlegende Probleme mit Bedienbarkeit, Geschwindigkeit oder Verlässlichkeit den Nutzen jeder zusätzlichen Funktion überlagern. Viertens könnte die Zielgruppe falsch eingeschätzt sein. Mein Vorgehen würde damit beginnen, eine belastbare Datengrundlage herzustellen: Nutzungsdaten je Funktion, Abbruchpunkte in den zentralen Abläufen, Supportanfragen und ergänzend direkte Gespräche mit Nutzern. Aus der Kombination von Zahlen und Gesprächen lässt sich meist eingrenzen, auf welcher Ebene das Problem liegt. Anschließend würde ich die Arbeitsweise ändern, indem für künftige Einträge vorab eine erwartete Wirkung mit Messgröße formuliert und nach der Auslieferung überprüft wird. Ebenso würde ich Kapazität dafür reservieren, wenig genutzte Funktionen zu verbessern oder zu entfernen, statt ausschließlich Neues zu bauen. Gegenüber den Stakeholdern würde ich die Diskussion bewusst von der Liefermenge auf die Wirkung verschieben und dafür das Sprint Review nutzen.
☝️ SingleEin Product Owner berichtet dem Vorstand, das Team habe im Quartal 47 Backlog-Einträge fertiggestellt. Welche Rückfrage sollte er sich selbst stellen?
✅Welche der 47 Einträge haben eine messbare Veränderung beim Nutzer oder im Geschäft bewirkt?
❌War die Schätzgenauigkeit über das Quartal hinweg stabil?
❌Wie viele Einträge blieben im Backlog offen?
❌Wie verhält sich die Zahl zum Vorquartal?
Die Zahl fertiggestellter Einträge ist eine Ausbringungsgröße. Ohne Wirkungsbezug legt sie nahe, dass Menge Wert bedeutet. Der Vergleich mit dem Vorquartal verschärft das Problem sogar, weil er zur Steigerung der Zahl einlädt.
← Alle ThemenIm Quiz üben