In Anlehnung einer alten Fernsehreklame für Damenhygieneartikel möchte ich sagen: Die Geschichte der Velocity ist eine Geschichte voller Missverständnisse. Und diese Missverständnisse haben sich verselbstständigt und manifestiert; auf eine Art, die versucht klassisches Management, Controlling, Finger-Pointing und Blaming durch die Hintertür wieder einzuführen.

Aber fangen wir mal von vorne an:

Schätzen und Planning Poker

Ich bin mir nicht sicher, wer sich als erster ausgedacht hat, sich mit Hilfe von so genannten Story Points über Stories zu unterhalten. Sicherlich hat der- oder diejenige sehr heere Absichten gehabt, wie man an den beiden grundsätzlichen Methoden sehen kann, auf deren Basis geschätzt wird.

1. Die Stacey Matrix

Die Stacey Matrix stellt fachliche und technische Herausforderungen in einem 2-dimensionalen Diagramm dar. Eine Story, die eine hohe technische Herausforderung darstellt, kann als kompliziert bezeichnet werden, fachlich herausfordernde Stories können dann komplex genannt werden.

Ist eine Story weder kompliziert noch komplex, dann ist sie vollständig verstanden und die Technik zum Umsetzen der Story ist gut beherrscht. Solch eine Story wird i.d.R. niedrig geschätzt, vielleicht mit einer 1 oder 2. Rein komplexe oder rein komplizierte Stories sind dann anders einzuschätzen; Schätzungen können dann, je nach Situation, Rahmenbedingungen und Team zwischen 2 und 8 liegen; mit einem Schwerpunkt bei 3 und 5. Stories die sehr komplex und ebenso kompliziert sind, will man eigentlich nicht im Sprint bearbeiten, da es höchst ungewiss ist, diese Story im Sprint wirklich abzuschließen. Je nach Team werden solche Stories hoch geschätzt (20 und mehr) oder anders behandelt (kleiner geschnitten, Spike herausgebrochen und vieles mehr …)

Ohne weiter in die Details der Stacey Matrix einsteigen zu wollen, so machen diese kurzen Ausführungen doch deutlich, dass die daraus entstehenden Werte keinen direkten Zusammenhang zu einer Team Performance aufweisen. Natürlich zieht das Team bei der Schätzung der Stories auch andere Aspekte (Teamkapazität, externe Einflussfaktoren usw.) hinzu, was aber neben den technischen und fachlichen Herausforderungen eher zweitrangig ist.

2. Referenzstories

Die zweite Möglichkeit zu einer Schätzung mit Story Points zu kommen ist der Vergleich mit einer (oder mehreren) Referenzstories. Dabei sucht sich das Team eine gut bekannte, erfolgreich bearbeitete Story einer mittleren Komplexität; also eine Schätzung von ca. 3 bis 8. Ausgehend von dieser Story kann nun jede weitere Story verglichen mit der Referenzstory geschätzt werden. Ist sie größer, komplexer, komplizierter als die Referenzstory, so muss sie also mehr Punkte erhalten und andersrum.

Auch hier zeigt sich, dass die Performance des Teams keine wesentliche Rolle spielt, die sich ergebenen Story Points also kaum eine valide Aussage über die Performace oder die Geschwindigkeit des Teams machen können.

Der Vollständigkeit halber sei erwähnt, dass man beide Ansätze auch kombinieren und ergänzend einsetzen kann.

3 Planning Poker

Wie läuft so eine Planungsrunde ab: wenn das Team über Stories spricht, sie einordnet bzgl. Komplexität, Kompliziertheit, vergleicht mit einer Referenzstory, die Rahmenbedingungen mit berücksichtigt, so macht sich jedes Teammitglied ein Bild. Dieses Bild wird im so genannten Planning Poker untereinander abgeglichen und das geht so: jedes Teammitglied zieht verdeckt eine Karte mit einer Schätzzahl aus der Fibonacci-Reihe (1, 2, 3, 5, 8, 13, 20, 40, 100 …). Dabei weicht die Schätzreihe von der Fibonacci-Reihe ab 20 (eigentlich 21 …) ab, um zum Ausdruck zu bringen, dass eine punktgenaue Schätzung spätestens ab 20 (aber vermutlich auch schon vorher) nicht möglich ist. Die Fibonacci-Reihe ist auch deshalb als Basis gewählt worden, weil sich quasi von Stufe zu Stufe eine (fast) Verdoppelung ergibt. Dadurch wird man gezwungen sich zu positionieren und eine eindeutige begründete Meinung zu bilden. Habe verschiedene Teammitglieder unterschiedliche Ansichten, so werden diese nach verschiedenen Methoden kondensiert (Durchschnitt bilden, höchste zieht, bestes Argument gewinnt, Thumb Voting usw. usf.)

Auch hier will ich nicht weiter ins Detail gehen, sondern einfach klar machen, dass auch und nicht zuletzt aufgrund der Schätzmethode keine Genauigkeit entstehen kann.

Grundsätzlich handelt es sich immer um eine Schätzung, deren Zweck es ist, das Team dazu zu befähigen, sich über Inhalt, Form, Technik, Fachinhalt usw. einer Story im klaren zu werden. So einfach. So wichtig.

Und was ist denn nun die Velocity???

ein bisschen Statistik …

Tatsächlich kann man die Velocity als eine statistische Größe in einem komplexen Zufallsexperiment betrachten. Betrachtet man das Ergebnis verschiedener Sprints über einen längeren Zeitpunkt, so ergibt sich eine Gaußsche Glockenkurve. Voraussetzungen dafür sind:

• langer Betrachtungszeitraum (> einige Monate)
• Unabhängigkeit des Teams von äußeren Einflüssen
• stabiles Team (keine Mitarbeiterwechsel, Krankheiten, Nebenbeitätigkeiten …)
• genau bekanntes technisches und fachliches Umfeld

Sind diese Voraussetzungen nicht gegeben, oder werden sie im Betrachtungszeitraum verletzt, so wird die statistische Größe Velocity (je nach Ausmaß der Störung) unbrauchbar. Tatsächlich habe ich in rund 25 Jahren Arbeitsleben diesen Idealzustand noch nicht ein einziges mal erlebt, oder auch nur davon gehört.

Aber gehen wir der Einfachheit mal davon aus, dass diese Bedingungen eingehalten sind und die Glockenkurve Bestand hat. Als Velocity bezeichnet man dann das Maximum der Kurve. Wohlgemerkt: das bedeutet auch, dass rund die Hälfte der Sprints diesen Wert nicht erreichen wird und die andere Hälfte oberhalb der ermittelten Velocity liegt. Eine Erklärung für sehr niedrige und sehr hohe Werte mag in Einzelfällen möglich sein, ist aber für die Gesamtaussage sinnfrei.

Der Sinn dahinter

Ja, aber was ist denn nun der Sinn hinter der Velocity? Was macht man denn nun damit, wenn man sie hat und valide ermittelt hat?

Nun, ja: wenn man in der Lage ist, das gesamte Backlog durchzuschätzen und die oben genannten Randbedingungen gelten, dann, und nur dann, ist die Velocity eine gut geeignete Größe um eine Forcast Prognose zu erstellen; also eine Aussage darüber, wann voraussichtlich das Backlog abgearbeitet sein wird.

Das ist dünn. Es gilt nur unter Ausnahmebedingungen, die im realen Arbeitsumfeld nur sehr schwer zu erreichen sind. Man verlangt und erwartet also einen Wert, der unter realen Bedingungen bestenfalls tendenzielle Aussagen machen kann.

Und warum wird sie trotzdem immer wieder von Stakeholder- oder Linienführungsseite verlangt?

Warum die Velocity immer noch ein gern geforderter Wert ist, erschließt sich, wenn man denn mal nachfragt, warum man denn diesen Wert wissen will. Die Antworten sind entlarvend:

• Um Sprints besser miteinander vergleichen zu können.
• Um ein Controlling durchführen zu können
• Um einen Forecast ableiten zu können
• Um die Entwicklung des Teams zu einem High Performance Team beurteilen zu können
• Um Teams miteinander vergleichen zu können
• Um den Wert eines Storypoints bestimmen zu können.
• …

D.h. es geht um ein Controlling; Kontrolle über die unterschiedlichsten Dinge, bis hin zu teaminternen Angelegenheiten. Story Points und die daraus resultierende Velocity ist dazu nicht geeignet.

Ja, natürlich darf und muss es ein Controlling geben. Der Sponsor hat ein vitales Interesse daran zu erfahren, ob er für sein Geld das Gewünschte erhält und ob er im Rahmen von Zeit, Geld und Qualität zu einem wertschöpfenden Ergebnis kommt. Wie man das sinnvoll gestalten kann, versuche ich mal in einem der nächsten Beiträge auszuführen.

zum Ende

Viele Themen habe ich nur kurz angerissen und es beschleicht mich das Gefühl, dass allein aus dem Thema Controlling in einem agilen Umfeld ein Buch entstehen könnte. Und wenn nicht ein Buch, dann sicherlich der eine oder andere Folgebeitrag.

Letztens sagte ein geschätzter Kollege, dass er gar keine Probleme mit der Velocity habe. Sein Team würde den Wert standardmäßig kommunizieren; für ihn sei das ein Zeichen von Transparenz. – Nun, ja. Und nein. Selbstverständlich stehe ich für 100%ige Transparenz. Informationen, die einen Einblick in die verschiedenen Aspekte der Arbeit eines Teams haben, dürfen und sollen gerne veröffentlicht werden. Die Velocity gibt aber nur sehr beschränkt Einblick (s.o.) und öffnet Tor und Tür für Fehlinterpretationen. Und deshalb: nein.

Wie seht Ihr das?