Team Velocity

Ziel: Leistungsfähigkeit des Teams kennen

• Team Velocity  =  Anzahl der Story Points, die das Team pro Iteration schafft
  
• Entkopplung von realen Kosten (PT) wird oft als Vorteil gesehen
• gilt nur für ein spezielles Team und muss sich erst „einschwingen“
  
• erlaubt dann gute Vorhersagen für zukünftige Iterationen
• soll nachhaltig und damit auf Dauer realistisch sein

Bei der Team Velocity geht es um die Arbeitsgeschwindigkeit eines Teams. Im Idealfall hat ein Team eine klare Vorstellung davon, wie viele Story Points es in einer Iteration schafft. Außerdem gelingt es dem Team dann recht genau, neue Anwendungsfälle mit ihrer Komplexität in Story Points abzuschätzen. Dann hätte es ein gutes Mittel, um auf der groben Ebene von Anwendungsfällen anzugeben, was es in welcher Zeit als Teilprodukt liefern kann. Genau dies ist die Zielsetzung von Story Points. Allerdings kann ein Team dies nicht aus dem Stand bewerkstelligen. Es muss sich erst langsam an die Methode heranarbeiten, denn es müssen ja erst einmal Referenzen für die Schätzung gebildet werden. In der Praxis sind die Schätzungen qua Story Points in den ersten Iterationen noch recht ungenau. Sie werden dann aber von Iteration zu Iteration genauer. 

Hierzu ein einfaches Beispiel: Ein Team schätzt alle User Stories eines Projektes mit Story Points ab. Einer Story, die vermutlich einen mittleren Entwicklungsaufwand verursacht, gibt es 8 Story Points. Einer anderen Story, die etwa halb so aufwendig wirkt, gibt es 5 Story Points. So werden alle Stories abgeschätzt. In der ersten zweiwöchigen Iteration schafft das Team User Stories mit insgesamt 32 Story Points. Daraus kann es eine Vorhersage für die nächste Iteration ableiten. Abschätzungen für neue User Stories, die zum Projekt dazukommen, werden immer besser, da es dann auch immer mehr Referenz-Stories gibt, an denen das Team sich orientieren kann.

Die Anzahl von Story Points, die ein Team in einer Iteration schafft, wird als Team Velocity (zu Deutsch: Teamgeschwindigkeit) bezeichnet. Möglichst präzise Vorhersagen darüber, in welchem Umfang ein Team in der nächsten Iteration Stories schaffen kann, sind dabei das eigentliche Ziel.

Das folgende Diagramm verdeutlicht diesen Zusammenhang. 

In dem Diagramm ist die Anzahl lieferbarer Story Points über die Entwicklungszeit aufgetragen. Die Teamgeschwindigkeit ist als Linie eingezeichnet. Das Diagramm kann also auch als Burn-Up-Chart mit eingezeichnetem idealen Burn-Up verstanden werden. Im Sinne des PM-Dreiecks gibt jeder Punkt auf der Linie einen realistischen Liefertermin zu einem gegebenen Umfang an. Jeder Punkt über der Linie stellt einen unrealistischen Liefertermin dar.

Betrachtet man die Team Velocity über einen längeren Zeitraum, erhält man Informationen darüber, wie sich die Effektivität eines Teams verändert. Dabei sollte man die Teamgeschwindigkeit allerdings immer im Zusammenhang mit dem Prinzip des Nachhaltigen Projektfortschritts sehen. 

Im klassischen Projektumfeld besteht die Gefahr, dass die wirtschaftlichen Interessen in den Vordergrund treten. Wohlgemerkt: Team Velocity ist kein Hilfsmittel, um die Teamgeschwindigkeit um jeden Preis zu maximieren. Es geht darum, realistische Vorhersagen treffen zu können.

Beispiel: Ein Projektmanager berichtete mir nach seinen ersten Gehversuchen mit agilen Techniken Folgendes: Durch die Arbeit mit dem Konzept der Team Velocity kam er auf die Idee, die Arbeitsgeschwindigkeit auch auf individueller Ebene zu erfassen und im Team transparent zu machen. Auf meine Nachfrage, wie sich das denn im Team ausgewirkt hat, kam die nicht ganz überraschende Antwort: „Na ja, die Motivation ging nach unten. Irgendwie wurde das als mangelnde Wertschätzung ausgelegt …“ Insbesondere hatten sich dadurch diejenigen Kollegen unfair behandelt gefühlt, die ihre Zeit investiert hatten, um externe Mitarbeiter im Projekt aufzugleisen. 

Dieses Beispiel macht deutlich, dass die Teamgeschwindigkeit ausschließlich als gemeinsame Leistung des Teams zu verstehen ist. Das Herunterbrechen auf eine individuelle Ebene ist nicht ratsam. Ebenso entscheidend für den erfolgreichen Einsatz der Technik ist die Erkenntnis, dass Team Velocity von einem stabilen Team ausgeht. Im klassischen Projektumfeld mit unklarer oder dynamischer Ressourcen-/Projekt-Zuordnung ist die Teamgeschwindigkeit deutlich schwieriger zu bestimmen bzw. deutlich weniger aussagekräftig. Dies ist ein ganz zentraler Punkt, denn ein wichtiger Vorteil agiler Prozesse ist ja gerade die zuverlässige Lieferung von Teilprodukten. Diese wiederum basiert aber auf der zuverlässigen Schätzung der Teamgeschwindigkeit.