Impact Score – Mehrwert aus Product-Owner-Sicht

Finanzielle Mittel, die in ein Produkt geflossen sind, sollen eine gute Rendite einbringen, einen attraktiven Return on Invest. Nehmen wir zum Beispiel Microsoft Excel: Ich vermute, dass 90 % der User nur 10 % des Leistungsspektrums von Excel nutzen. Dieser Teil trägt dann maßgeblich zum ROI bei. Der Product Owner achtet auf die Rentabilität. Ihm oder ihr geht es darum, genau diese Features zu identifizieren, die den größten Mehrwert liefern.

Story Points: Funktionalitäten schätzen

Für gewöhnlich schätzen wir in sogenannten Story Points, um die Größe von User Stories zu beziffern. Achtung: Wir schätzen hier nicht in Arbeitsaufwand, sondern in Funktionalitäten. Geschätzt wird im Backlog Refinement vom den Entwicklerinnen und Entwicklern, also von jenen Fachleuten, die die User Stories anschließend umsetzen werden. Nach dem Schätzen haben wir ein Bild davon, wie sich die User Stories ihrer Größe nach relativ zueinander verhalten, wo noch inhaltliche Unklarheit herrscht und welche Stories kleiner geschnitten werden müssen, bevor sie innerhalb eines Sprints umsetzbar sind.

Value Points: Mehrwert schätzen

Doch was wäre, wenn wir nicht nur in Story Points schätzen, sondern auch in Value Points? Also bezogen auf den Wertbeitrag, den diese User Story (z. B. eine Funktionalität einer Software) für das Produkt liefert? Value Points können vom Product Owner geschätzt werden, aber auch von Kunden und Usern, vom Management und anderen Stakeholdern. Kurz gesagt: Diejenigen, für die die User Story einen zusätzlichen Nutzen schaffen soll, beziffern diesen Nutzen. Das Backlog besteht nun aus User Stories, die nicht nur aus der Entwicklungssicht heraus geschätzt wurden, sondern auch aus der Nutzersicht. Das erhöht die Interaktion des Product Owners mit Nutzern, Kunden und dem Management, gibt dem Entwicklungsteam einen Nordstern und unterstützt den Product Owner bei der Priorisierung des Backlogs.

Am einfachsten und schnellsten geht das Schätzen von Story und Value Points mit Magic Estimation, einer Schätzmethode, die von borisgloger entwickelt wurde. Hiermit lassen sich mehr als 50 User Stories im Team innerhalb von circa 20 Minuten schätzen.

Am Ende haben wir also zwei Werte – einen technischen (Story Points) und einen ökonomischen (Value Points). Wenn wir nun die Value Points durch die Story Points dividieren, erhalten wir den Mehrwert pro Story Point für eine User Story: den Impact Score oder „Bang for the Buck“-Score, wie David Griffiths ihn nennt.

Wir wissen also, wie groß der Impact einer User Story ist, indem wir den Mehrwert für die Nutzer mit der technischen Größe in Relation setzen. Der Product Owner kann sich bei der Priorisierung am Impact der User Stories orientieren, um den größtmöglichen Mehrwert zu schaffen.

Kein Selbstzweck: Mehrwert des Schätzens

Wie die Schätzung selbst suggeriert auch der Impact Score eine Scheingenauigkeit, die de facto so nicht existiert. Er bietet jedoch eine wunderbare Möglichkeit, um zum Ursprung von User Stories zurückzukommen: User Stories sind die Grundlage für eine Konversation.

Für die Tabelle oben wenden wir diese Faustregeln an:

– Ein eindeutig hoher Impact Score (Story A und C) zeigt einen hohen Mehrwert bei verhältnismäßig geringer technischer Größe.
Hypothese: User Story umsetzen!

– Ein eindeutig niedriger Impact Score (Story B und E) zeigt eine zu hohe technische Größe bei zu kleinem Mehrwert.
Hypothese: User Story verwerfen.

– Alles dazwischen ist uneindeutig.
Hypothese: Diese User Stories sind zu besprechen, um zu entscheiden, ob Zeit und Energie für Refinement und Umsetzung investiert werden sollen.

Der Vorteil des Impact Scores: Eindeutige User Stories – im positiven wie negativen Sinne – werden innerhalb weniger Minuten identifiziert und müssen nicht besprochen werden. Die wirklich wertvollen Gespräche und Interaktionen finden zu jenen Features statt, deren Umsetzung von der Weitsicht und dem Fingerspitzengefühl des Product Owners abhängig ist.

Das heißt nicht, dass die User Stories mit geringerem Impact Score nicht später einmal wichtig werden können. Aber sie sind nicht die Priorität. Wenn wir uns das heutige Microsoft Excel ansehen, umfasst es nicht nur die meistgenutzten Funktionen für die Grundrechenarten, sondern auch die hochentwickelten Features für Wissenschaft und Forschung, Finanzmathematik und die attraktive Visualisierung komplexer Ergebnisse. Genau dieser Umfang macht das Produkt so wertvoll, auch wenn die meisten Nutzerinnen und Nutzer nur einen kleinen Teil des Leistungsspektrums nutzen.

Triologie zum Agile Procurement

Dies ist der dritte Blogbeitrag der Triologie zum Agile Procurement. Der erste Teil „Übler Cocktail: Agilität und Werkverträge“ handelt davon, warum agile Arbeitsweisen und Werkverträge nicht zusammenpassen. Im zweiten „Split the Difference: Kreative Vertragslösungen für agile Projekte“ beschreibe ich ein faires Konzept für Dienstverträge, das Jeff Sutherland unter dem Titel „Money for nothing“ vorgestellt hat. Der Impact Score begünstigt dieses Vertragsmodell. Deswegen erhalten Auftraggeber in diesem Beitrag mit dem Impact Score ein Instrument an die Hand, mit dem sie sicherstellen können, dass das im Dienstvertrag definierte Budget auch zielgerichtet verwendet wird.

Und die Product Owner möchte ich gleichzeitig dazu ermutigen, mit den Kunden, Nutzern und Stakeholdern in die Interaktion und den Dialog zu treten.

Titelbild: Unsplash License, Sharon McCutcheon