Outcome vor Output: warum Velocity die falsche Zahl ist

// Sprint-Report, wie er im Statusdeck landet
const sprint42 = {
  storyPointsCommitted: 34,
  storyPointsCompleted: 38,
  ticketsDone: 17,
  velocityTrend: "up",
};

Aus diesem Objekt folgt genau eine Aussage: Das Team hat mehr Punkte abgeschlossen, als es zugesagt hatte. Ob ein Nutzer dadurch schneller ans Ziel kommt, ob ein System stabiler läuft, ob irgendwo Umsatz entsteht – dafür gibt es hier kein Feld, und es lässt sich auch nachträglich keines hineinrechnen. Trotzdem wandert genau diese Kurve Sprint für Sprint in Berichte, wird zwischen zwei Teams verglichen und landet gelegentlich neben dem Umsatz auf einer Board-Folie.

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.

Die Trennlinie verläuft zwischen einer beobachteten Aktivität und der belegbaren Veränderung, die daraus folgt.

Output

• Beobachtung · Was wurde gebaut oder abgeschlossen?
• Beispiele · Features, Tickets und Story Points
• Nutzen · Planung und Nachverfolgung der Arbeit
• Grenze · Belegt noch keine Veränderung beim Nutzer

Outcome

• Beobachtung · Was hat sich im Verhalten oder Ergebnis verändert?
• Beispiele · Aktivierung, Zeit bis zum ersten Wert und Fehlerquote
• Nutzen · Prüft, ob eine Lösung auf das Ziel einzahlt
• Grenze · Benötigt Kontext und eine belastbare Messung

Damit bleibt Velocity als internes Planungsmaß brauchbar, ohne zur Aussage über Produktivität oder Geschäftswert zu werden.

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 ernüchternd. 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, mit dem ich dabei die besten Erfahrungen gemacht habe, 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 genau dieser Pfeil fehlt in den Berichten, die ich zu sehen bekomme, fast durchgängig.

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.

DORA hilft, mit einer Einschränkung: Auch diese 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 sammelt 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 notwendig, aber Wirkung ist das Ziel. Erledigte Tickets, Story Points und Velocity beschreiben Arbeit und Planung – nicht, ob sich für Nutzer oder Geschäft etwas verbessert hat. Als interne Planungshilfe sind sie legitim; als Erfolgsmaß fürs Management lenken sie in die falsche Richtung, weil eine Zielzahl optimiert wird und Beschäftigung noch keine Wirkung belegt.

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 nüchternes Eingeständnis 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

• Martin Fowler: CannotMeasureProductivity und XpVelocity
• Teresa Torres: Continuous Discovery Habits (2021)
• Nicole Forsgren, Jez Humble, Gene Kim: Accelerate (2018); Four Keys to measure DevOps performance
• Eric Ries: The Lean Startup – Principles (2011)
• Neal Ford, Rebecca Parsons, Patrick Kua: Building Evolutionary Architectures – Fitness Functions (2017)

Wie fandest du diesen Beitrag?

Kommentare