Fortschritt in Features messen

Sie sind als Product Owner teil eines Scrum-Teams. Frisch im Unternehmen und mit den positiven Eindrücken des Bewerbungsverfahrens gehen Sie ans Werk. Und stellen nach und nach fest, dass es hier mit Selbst-Organisation nicht so weit her ist. Zunächst war es nur die Bitte, ein Features in den laufenden Sprint aufzunehmen.
Es stellt sich heraus, dass es im Unternehmen vor allem darum geht, Features zu liefern. Je mehr Features, desto wertvoller die Software. Sie sind in einer Feature-Factory gelandet.

Inhalt:

Grafische Darstellung eines Fließbands.
In der Feature-Factory geht es nicht um Ergebnisse, sondern, wie am Fließband, um geleistete Arbeit.

Ihre Aufgabe als Product Owner

Als Product Owner versuchen Sie, Einfluss darauf zu nehmen. Immerhin nehmen Sie Ihren Job ernst und fühlen sich dafür verantwortlich, den Wert des Produktes zu maximieren, das aus der Arbeit des Entwicklungsteams entsteht.
Doch die Stakeholder messen Ihre Arbeit eher an termingerechter Lieferung der versprochenen Features. Was tun?
Machen Sie es den Stakeholdern einfach, Ihren Feature-Glauben abzulegen, in dem Sie Ihre Sprache sprechen. Lassen Sie Zweifel am Glauben an der Wertschöpfung durch fristgerechte Lieferung entstehen. Leiten Sie sie dahin, Features nicht an Terminen, sondern am Ergebnis zu bewerten.

Sprint-Kosten in Relation zum erwarteten Ergebnis

Dazu kann man sich an vergangenen Situationen orientieren und zum Beispiel diskutieren:

  • Wie oft wird Feature X tatsächlich benutzt?
  • Wird es selten genutzt, aber ein wichtiger Hygiene-Faktor, oder passt es nicht zu Ihren Kunden?
  • Welche regelmäßigen Kosten verursacht es?
  • Wie hoch waren die Entwicklungskosten des Features?
  • Wie hoch war die Cost of Delay by Duration dieses Features, mit anderen Worten, wie viel Umsatz konnte nicht realisert werden, weil ein besseres Feature erst später entwickelt werden konnte?

Letztlich führen diese Fragen zu einer Diskussion über den erwarteten Wert der Features im Vergleich untereinander und in Relation zu den Kosten eines Sprints.

Wie viel ein Sprint kostet

Zunächst die Personalkosten: die Gehälter der Scrum-Team-Mitglieder. Aus der Diskussion über den Wert der Features kennen Sie außerdem die Kosten, die durch spätere Lieferung eines Features entstehen.

  • Kosten eines Sprints (Monatsgehälter von 8 Personen): € 50.000
  • Feature A: € 10.000 mehr Umsatz nach Fertigstellung über einen Sprins
  • Feature B: € 15.000 mehr Umsatz nach Fertigstellung über drei Sprints
  • Feature C: € 25.000 mehr Umsatz nach Fertigstellung über zwei Sprints
Kosten und Ersparnis bei Priorisierung nach Umsatz.
Auf den Umsatz zu achten führt nicht immer zu den besten Entscheidungen.
Kosten und Ersparnis bei Priorisierung nach Umsetzungsdauer.
Die Umsetzungdauer spielt durchaus eine Rolle.
Kosten und Ersparnis bei Priorisierung nach Cost of Delay by Duration.
Erst wenn man die Umsatzausfälle berachtet, findet man das optimale Ergebnis.

Kundenzentrizität

Hier sind wir inmitten der Product-Owner-Kernaufgabe, nämlich den Wert des Produktes zu maximieren, das aus der Arbeit des Entwicklungsteams entsteht.

Jetzt messen wir Fortschritt nicht mehr in Features, sondern in geschaffenem Wert.

Diese Basiszahlen sind die Grundlage für viele spannende Diskussionen zur Rentabilität, dem ROI, zu Headcount. Sie eröffnen den Weg zu relevanterem Controlling (»Beyond Budgeting«) und sind doch nur die interne Sicht der Kundenzentrizität.


Ihr Sascha A. Carlin

Als Agile Coach verhelfe ich Führungskräften in der Softwareentwicklung zu mehr Wirksamkeit.

Kontaktaufnahme jederzeit via E-Mail oder Telefon +49 30 40782375.