Mike Bild
post

Outcome vor Output: warum Velocity die falsche Zahl ist

Erledigte Tickets sind billig, Wirkung ist das Ziel. Warum Velocity im Management-Reporting in die Irre führt und wie man Teams stattdessen an Outcomes ausrichtet.

≈ 9 Min. Lesezeit
SoftwareProdukt

In fast jedem Review-Meeting, in das ich in den letzten Jahren als Berater geraten bin, taucht irgendwann dasselbe Chart auf: die Velocity-Kurve. Ein Balkendiagramm, Sprint für Sprint, und die stille Erwartung im Raum, dass ein höherer Balken etwas Gutes bedeutet. Manchmal wird die Zahl sogar zwischen zwei Teams verglichen, gelegentlich landet sie in einem Board-Report neben dem Umsatz. Und jedes Mal denke ich dasselbe: Diese Zahl beantwortet eine Frage, die niemand gestellt hat.

Die Frage, die tatsächlich zählt, lautet nicht "Wie viele Story Points hat das Team abgearbeitet?", sondern "Was hat sich für den Nutzer, für das System, für das Geschäft dadurch verändert?". Das ist der Unterschied zwischen Output und Outcome. Und wer ihn verwischt, optimiert ein Team systematisch auf Beschäftigung statt auf Wirkung.

Velocity misst Vorhersagbarkeit, nicht Produktivität

Fangen wir bei der Quelle an, denn Velocity ist zu Unrecht in Verruf geraten. Martin Fowler hat schon vor bald zwei Jahrzehnten präzise beschrieben, wofür die Zahl gedacht war: als Kalibrierungswerkzeug für Schätzungen. Das Prinzip heißt "Yesterday's Weather" – wir gehen davon aus, dass ein Team im nächsten Sprint ungefähr so viel schafft wie im letzten. Damit lassen sich Planungen realistisch halten, ohne dass jemand heldenhafte Zusagen macht.

Story Points sind dabei eine teamspezifische Baseline. Sie bedeuten für Team A etwas anderes als für Team B, weil sie relativ zum jeweiligen Kontext geschätzt werden. Genau deshalb ist der Vergleich zweier Teams anhand ihrer Velocity nicht nur ungenau, sondern schlicht sinnlos – man vergleicht zwei verschiedene Maßeinheiten und tut so, als wären es dieselben.

Und dann passiert das Vorhersehbare. Sobald Velocity zum Management-Ziel wird, wird sie gespielt. Teams schätzen großzügiger, splitten Tickets feiner, deklarieren Nebensächliches als Story. Die Kurve steigt, die Lieferung bleibt gleich. Das ist keine Böswilligkeit, das ist Goodhart's Law in Reinform: "When a measure becomes a target, it ceases to be a good measure." Jede Zahl, die man zum Erfolgsmaß erhebt, hört in demselben Moment auf, ehrlich zu sein.

Ich will Velocity also gar nicht verteufeln. Intern, als Planungs- und Vorhersagehilfe, ist sie völlig legitim und nützlich. Der Fehler liegt nicht in der Zahl, sondern in ihrer Beförderung zum Erfolgsmaß. Das ist eine wichtige Differenzierung, die im Eifer der "Velocity ist böse"-Debatten gern verschwindet.

Der wahre Output ist Wirkung – und die lässt sich nicht direkt messen

Fowlers eigentlich radikaler Punkt kommt danach: "True output is business value." Der wahre Ertrag eines Teams ist nicht die Menge an Features, sondern der geschaffene Wert. Sein Beispiel bringt es auf den Punkt: Ein Team, das weniger Features liefert, aber zehn Millionen Gewinn erzeugt, ist produktiver als eines mit mehr Features und fünf Millionen Wert.

Der Haken daran ist unbequem. Business Value hinkt der Investition zeitlich nach, oft um Jahre. Was ein Team heute baut, zahlt sich – wenn überhaupt – erst später aus, verzahnt mit Markt, Vertrieb, Timing und einem Dutzend anderer Faktoren. Eine sofortige, saubere Produktivitätsmessung ist damit schlicht unmöglich. Fowlers ehrliche Konsequenz: "We have to admit our ignorance." Wir können Produktivität nicht direkt messen. Punkt.

Das klingt entmutigend, ist aber befreiend. Denn wenn die perfekte Zahl nicht existiert, hören wir auf, sie zu suchen, und wenden uns dem zu, was wir tatsächlich beeinflussen und beobachten können: der Wirkung unserer Arbeit auf Nutzer und System.

Outcome statt Output: der Kern moderner Produktarbeit

Genau hier setzt die Produktseite an. Teresa Torres unterscheidet in ihrer Arbeit zu Continuous Discovery sauber: Outputs sind das, was wir bauen – Features, Screens, Endpoints. Outcome ist die Veränderung im Verhalten von Nutzern, die einen Wert für Kunde und Geschäft erzeugt. Wer Outputs zum Ziel erklärt, produziert einen "disconnect" zwischen der Aktivität des Teams und dem gelieferten Wert. Das Team ist ausgelastet, das Board ist voll, und trotzdem bewegt sich beim Nutzer nichts.

Marty Cagan formuliert dieselbe Beobachtung noch schärfer: "Empowered teams get outcomes, feature teams get output." Ein Feature-Team bekommt eine Roadmap vorgesetzt und arbeitet sie ab – Output. Ein "empowered" Team bekommt ein Problem und ein Outcome-Ziel und darf selbst herausfinden, wie es dorthin kommt. Der Unterschied ist nicht kosmetisch. Er entscheidet darüber, ob Menschen mitdenken oder nur abarbeiten.

Das Werkzeug, das ich in Beratungen am häufigsten empfehle, ist der Opportunity Solution Tree. An der Wurzel steht genau ein Outcome, zum Beispiel "Aktivierungsrate um X Prozent erhöhen". Darunter verzweigen sich Opportunities – konkrete Nutzerprobleme oder -bedürfnisse, die auf dieses Outcome einzahlen. Darunter wiederum Solutions, und ganz unten die Experimente, mit denen wir prüfen, ob eine Lösung tatsächlich wirkt. Der Baum zwingt zu der Frage, die die Velocity-Kurve nie stellt: Zahlt das, was wir gerade bauen, überhaupt auf die Wurzel ein?

graph TD
    subgraph output["Output-Sicht (Vanity)"]
        B[Backlog] --> S[Sprint]
        S --> V["Velocity-Chart<br/>viele erledigte Tickets"]
        V --> U["up and to the right"]
    end
    subgraph outcome["Outcome-Sicht"]
        O["Outcome<br/>activation rate +X%"] --> OP1[Opportunity A]
        O --> OP2[Opportunity B]
        OP1 --> SOL[Solution]
        SOL --> EXP[Experiment]
    end
    V -. "bewegt der Output<br/>die Wurzel?" .-> O

Das Diagramm zeigt die beiden Welten nebeneinander. Links die Output-Pipeline, die zuverlässig nach oben zeigt. Rechts der Baum, der die Wirkung nachvollziehbar macht. Der gestrichelte Pfeil dazwischen ist die eigentliche Managementfrage – und in den meisten Organisationen ist genau dieser Pfeil nie gezeichnet.

Vanity Metrics: die Engineering-Variante der Selbsttäuschung

Eric Ries hat für diese Sorte Zahlen im Lean-Startup-Kontext den Begriff Vanity Metrics geprägt. Registrierungen, Pageviews, Downloads – Zahlen, die "up and to the right" gehen und sich gut anfühlen, ohne echten Fortschritt zu belegen. Velocity und erledigte Tickets sind die Engineering-Variante genau dieses Musters. Sie steigen zuverlässig, sie erzeugen ein gutes Gefühl, und sie sagen nichts darüber, ob wir dem Ziel näher gekommen sind.

Dem gegenüber stehen Actionable Metrics: Zahlen, die eine Ursache-Wirkungs-Beziehung zeigen und aus denen eine Entscheidung folgt. Die Fortschrittseinheit ist bei Ries nicht "Feature ausgeliefert", sondern "validated learning" – bestätigtes Lernen darüber, was beim Nutzer tatsächlich wirkt. Der Rahmen dafür heißt Innovation Accounting, der Zyklus Build-Measure-Learn.

In der Praxis heißt das: Man instrumentiert nicht, was man gebaut hat, sondern was der Nutzer daraufhin tut. Ein Event, das ein Outcome trackt, sieht anders aus als eines, das Output zählt.

// Actionable: measures what actually moves the user
track("activation_completed", {
  userId,
  cohort,
  timeToValueSeconds, // how fast does the user reach first value?
});

// Vanity: feels like progress, says nothing about impact
// track("features_shipped", { count });
// track("story_points_done", { total });

Der entscheidende Schritt kommt danach: Man rollt das Feature hinter einem Flag aus und vergleicht das Outcome-Delta zwischen zwei Cohorts. Erhöht die neue Lösung die Aktivierungsrate messbar, oder nicht? Das ist Build-Measure-Learn in einer Zeile Infrastruktur – und es verlagert die Erfolgsfrage vom "haben wir es gebaut?" zum "hat es gewirkt?".

Bessere Proxys: DORA und Fitness Functions

Nun wird an dieser Stelle gern eingeworfen: Es gibt doch DORA. Die vier Kennzahlen aus der Accelerate-Forschung von Forsgren, Humble und Kim – Deployment Frequency, Lead Time for Changes, Change Failure Rate und Time to Restore Service – sind ein großer Fortschritt. Sie messen bewusst Team-Outcomes statt individueller Outputs. Ausdrücklich kein Lines-of-Code, keine Story Points, keine Auslastung, weil das siloartige Beschäftigungszahlen sind. Und sie balancieren Geschwindigkeit gegen Stabilität, sodass man nicht eine Zahl auf Kosten des Gesamtsystems optimieren kann.

Ich schätze DORA sehr, aber ich sage in Beratungen immer denselben Satz dazu: Auch DORA-Metriken sind Proxys, keine echten Outcomes. Deployment Frequency ist nicht Nutzerwirkung. Ein Team kann fünfzigmal am Tag deployen und trotzdem am Bedarf vorbei. DORA misst die Fähigkeit, schnell und stabil zu liefern – ein exzellenter Indikator für Delivery-Gesundheit, aber eben nicht das Ziel selbst. Wer das verwechselt, hat nur eine Vanity-Zahl durch vier ersetzt.

Auf der Architekturebene gibt es ein Instrument, das mir besonders am Herzen liegt, weil es Outcome ausführbar macht: Fitness Functions aus der Evolutionary Architecture von Ford, Parsons und Kua. Eine Fitness Function ist eine objektive, automatisierte Bewertung einer Architektureigenschaft. Statt in einem Ticket "Performance verbessert" abzuhaken, schreibt man einen Test, der die Systemwirkung selbst prüft:

def test_checkout_latency_stays_within_budget():
    """Architectural fitness function: checkout stays fast under load."""
    result = load_test(endpoint="/checkout", concurrent_users=200)

    assert result.p99_ms < 500       # latency budget, not a story point
    assert result.error_rate < 0.01  # reliability is the real outcome

Der Charme daran: Erfolg ist hier keine Statusmeldung mehr, sondern eine messbare Systemeigenschaft, die entweder gehalten wird oder nicht. Der Test ist grün, weil das System die versprochene Wirkung liefert – nicht, weil jemand eine Story auf "done" geschoben hat. Ähnlich funktionieren Consumer-Driven Contracts, etwa mit Pact: Ein Test schlägt fehl, wenn ein Service ein Versprechen gegenüber seinem Konsumenten bricht. Auch das ist ein outcome-naher Test – er prüft die tatsächliche Wirkung an der Schnittstelle statt die bloße Existenz von Code.

Wie man Teams wirklich auf Outcome ausrichtet

Wenn ich das in einer Organisation aufsetze, folge ich einem einfachen Ablauf. Er ist bewusst schlank, weil der ganze Sinn der Übung ist, Prozess-Overhead durch Klarheit zu ersetzen, nicht neue Zeremonien zu schaffen.

flowchart LR
    A["Outcome definieren<br/>ein Ziel, messbar"] --> B["Opportunities<br/>Nutzerprobleme kartieren"]
    B --> C["Experimente<br/>hinter Feature-Flags"]
    C --> D["Wirkung messen<br/>Cohort-Delta"]
    D -->|"wirkt"| E["skalieren"]
    D -->|"wirkt nicht"| B

Am Anfang steht genau ein Outcome, formuliert als messbare Verhaltensänderung – nicht "Checkout-Redesign ausliefern", sondern "Abbruchrate im Checkout senken". Dazu passt der Gedanke der North Star Metric und, auf Zielebene, OKRs: Das Objective beschreibt die Richtung, die Key Results sind die Outcome-Signale, an denen wir Fortschritt erkennen.

Der zweite Schritt kartiert die Opportunities: An welchen Stellen bricht der Nutzer tatsächlich ab, wo entsteht Reibung? Erst danach kommen Lösungen, und die werden nicht ausgerollt und abgehakt, sondern als Experiment hinter einem Flag getestet. Zeigt das Cohort-Delta eine Wirkung, skalieren wir. Zeigt es keine, gehen wir zurück zu den Opportunities – ohne schlechtes Gewissen, denn ein widerlegtes Experiment ist validated learning und damit selbst ein Ergebnis.

Ein wichtiger Vorbehalt gehört dazu, sonst tappt man in die nächste Falle. Goodhart gilt auch für Outcome-KPIs. Auch eine Aktivierungsrate lässt sich spielen, und der Zeitverzug aus Fowlers Beobachtung bleibt bestehen: Wirkung braucht Zeit, und die Attribution ist selten eindeutig. Wer ein Outcome-Ziel setzt, muss diese Unschärfe einkalkulieren, statt sie wegzudefinieren – sonst konstruiert man falsche Kausalitäten und ist keinen Schritt weiter als beim Velocity-Chart.

Fazit

Der rote Faden durch all das ist einfach: Output ist billig, Outcome ist das Ziel. Erledigte Tickets, Story Points und Velocity messen, wie beschäftigt ein Team ist – nicht, ob seine Arbeit etwas bewirkt. Sie sind als interne Planungshilfe legitim, aber als Erfolgsmaß fürs Management führen sie zuverlässig in die Irre, weil jede Zielzahl gespielt wird und weil Beschäftigung nicht mit Wirkung korreliert.

Der Ausweg ist keine bessere Einzelzahl, sondern eine Haltung. Wir richten Teams an einem messbaren Outcome aus, machen die Wirkung über Actionable Metrics, Fitness Functions und Experimente sichtbar, und behandeln DORA als das, was es ist – einen guten Proxy für Lieferfähigkeit, nicht als Ziel. Das Ergebnis ist in meiner Erfahrung kein schwererer, sondern ein leichterer Prozess: kürzere Zyklen, weil wir Irrwege früh abbrechen; weniger Reibung, weil Teams selbst entscheiden dürfen; und höhere Qualität, weil Erfolg an der Wirkung hängt und nicht an der Statusfarbe eines Tickets.

Fowlers unbequeme Ehrlichkeit bleibt der beste Ausgangspunkt: Wir können Produktivität nicht direkt messen. Aber wir können aufhören, die falsche Zahl zu feiern, und anfangen, die richtige Frage zu stellen – bewegt das, was wir bauen, überhaupt die Wurzel?

Weiterführende Quellen

Kommentare