Gerrit Beine adesso AG

Die meisten Unternehmen fordern keine wertvolle Software, sie fordern geplante Software. Der Product Owner muss sicherstellen, dass Software in jedem Fall wertvoll ist.

Das erste der zwölf Prinzipien hinter dem agilen Manifest lautet: „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen“. Während viele Teams Best Practices durch die frühe und kontinuierliche Auslieferung kennen und auch anwenden, ist die Bestimmung, was wertvolle Software ist, oft nicht so trivial.

Gerade der Product Owner muss aber wissen, ob die Software der Vorstellung seines Kunden von „wertvoll“ entspricht. Dazu gibt es etliche Methoden, die allerdings bisher keinen Eingang in das übliche Curriculum der Product-Owner-Zertifizierung gefunden haben.

Keine Software ohne Nutzen

Software zu entwickeln ist für Unternehmen kein Selbstzweck. Die Entwicklung von Software wird als teuer empfunden, auch wenn Tom DeMarco diese Gefühle seit vielen Jahren kritisch hinterfragt. Also muss die zu entwickelnde Software einen möglichst großen Nutzen haben. In der Regel wird dieser Nutzen vor der Entwicklung durch einen Business Case beschrieben, in dem Kosten und Nutzen für das Unternehmen betrachtet und auf dessen Grundlage entschieden werden kann, ob das Projekt durchgeführt wird oder nicht.

Leider kommt es viel zu häufig vor, dass der Business Case die einzige ökonomische Bewertung eines solchen Projekts bleibt. Projekthäuser verfolgen zwar in der Regel den Earned Value bei Festpreisprojekten, aber dieser steht mit dem Wert der Software in keinem Zusammenhang. Vor allem agiles Projektmanagement erlaubt es, die ökonomische Betrachtung des Business Case auf einzelne Aspekte eines Projekts herunterzubrechen und immer wieder neu zu bewerten. Backlog Grooming muss sich nicht nur auf die fachlichen Aspekte von User Stories beschränken, sondern kann auch mit betriebswirtschaftlicher Brille erfolgen.

In seinem Video „Agile Product Ownership in a Nutshell“ hat Henrik Kniberg schön illustriert, wie eine Wertschöpfungskurve in einem agilen Projekt aussehen kann (Abb. 1). Zunächst liegt der Schwerpunkt auf dem Wissenszuwachs im Team. Der Zeitraum sollte möglichst kurz sein, um schnell maximalen Kundennutzen zu generieren.

Abb. 1: Wertschöpfungskurve in einem agilen Projekt; für kurze Zeit liegt der Schwerpunkt auf dem Wissensgewinn für das Team, danach auf der Schaffung von Wert für den Kunden; Quelle: Henrik Kniberg: „Agile Product Ownership in a Nutshell“

Abb. 1: Wertschöpfungskurve in einem agilen Projekt; für kurze Zeit liegt der Schwerpunkt auf dem Wissensgewinn für das Team, danach auf der Schaffung von Wert für den Kunden; Quelle: Henrik Kniberg: „Agile Product Ownership in a Nutshell“

Aber wie muss das Backlog priorisiert werden, damit eine solche Kurve erreicht werden kann? Die Basis dafür lässt sich in einer trivialen Formel ausdrücken (Abb. 2).

Abb. 2: Formel für eine Wertschöpfungskurve in einem agilen Projekt

Abb. 2: Formel für eine Wertschöpfungskurve in einem agilen Projekt

Die Bewertung der einzelnen Backlog Items kann dabei mit verschiedenen Modellen geschehen.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Business Technology 2.16 - "Digitale Disruption"

Alle Infos zum Heft
244538Tipps und Tricks für agile Product Owner
X
- Gib Deinen Standort ein -
- or -