Als Agile Consultant die Velocity bewerten

Die meisten von Ihnen werden wohl in einem festen Team arbeiten. Einige werden aber auch als Berater für Scrum und agile Methoden in anderen Firmen tätig sein. Wenn der potenzielle Kunde vorab ein Commitment bezüglich des Projektumfangs haben möchte, kann das ein Problem darstellen.

In der Ausschreibungsphase hat der Consultant nämlich noch nicht genug Informationen, um den Backlog einschätzen zu können. Hinzu kommt außerdem, dass man sein eigenes oder ein fremdes Team einschätzen muss, ohne Vorkenntnisse über das Projekt zu haben. Das kann schwierig werden.

Wie schätzt man die Velocity ein?

Im Prinzip kommt es hierbei darauf an, die Velocity sogar in noch nicht ganz überschaubaren Situationen einschätzen zu können.

Einerseits sind die Einheiten für die Bewertung (Story Points) relativ und es ist schwierig unterschiedliche Teams zu vergleichen. Andererseits kann man, wenn ein Team ein Projekt A durchgeführt hat und dann mit Projekt B anfängt, die Velocity aus dem ersten Projekt nutzen, um die des zweiten Projekts einzuschätzen. Das geht aber nur, solange die Einheiten in den verschiedenen Projekten gleich bleiben. Wenn eine Story aus Projekt A fünf Points hatte und genauso umfangreich ist, wie eine Story mit fünf Points aus Projekt B, kann man die bisherige Velocity übernehmen.

Das eigentliche Problem ist, wenn ein Team noch gar keine Angaben zur Velocity vorweisen kann.

Wenn man schon ein Team für die Velocity Bewertung hat

Also, Sie haben zwar ein Team, es gibt aber noch keine Daten bezüglich dessen Velocity. Lassen Sie die Teammitglieder dann einfach ganz normal die gewünschten Stories mit Story Points bewerten – auch wenn sie vielleicht keine Ahnung haben, was ihre Velocity sein könnte. Sie können jedoch trotzdem sagen, dass sich die Summe der Stories auf beispielsweise 300 Points beläuft.
Lassen Sie das Team nun den Sprint planen.

Meine Lieblingsmethode, einen Sprint zu planen, ist sich eine Story zu nehmen und in Tasks aufzuteilen, die Tasks dann mit Stundenangaben zu bewerten und das Team zu fragen, ob es dazu ein Commitment abgeben kann. Das wird dann mit weiteren User Stories wiederholt bis der Sprint voll ist.

Nehmen wir an, das Team hat zu den User Stories X, Y und Z ein Commitment abgegeben. Über die Velocity konnte noch nicht gesprochen werden, weil es dazu noch keine Daten gibt. Allerdings gibt es Story Points für alle Stories.

Also kann man die Points der drei Stories zusammenzählen und hat damit einen Ausgangspunkt für die zukünftige Velocity. Das sollte bei der Planung eines weiteren Sprints wiederholt werden. Das Team kann dann vielleicht Commitments für die Stories M, N, O und P abgeben (die wahrscheinlich eine andere Anzahl an Story Points haben werden).

Die beiden Ergebnisse können Sie als Rahmen zur Orientierung nutzen (z. B. 18 – 22 Points). Unter Umständen können Sie das noch abändern – wenn Sie das Gefühl haben, das Team könnte sich in den ersten Sprints leicht überschätzen (was die meisten Teams tun). In diesem Fall können Sie ein paar Punkte abziehen.

Wenn man noch kein Team hat um die Velocity zu bestimmen

Mit mehreren Unbekannten, wird die Situation zum Schätzen der Velocity komplizierter. Nehmen wir einmal an, Sie haben noch gar kein Team. Ihnen stehen genügend Mitarbeiter zur Verfügung, es ist aber noch nicht klar, wer bei diesem Projekt dabei sein wird. Suchen Sie einfach ein paar Mitarbeiter aus, die die oben genannten Schritte stellvertretend für das künftige Scrum Team ausführen.

Dann können Sie Ihrem Chef oder Kunden sagen:

“Ein Team mit drei Senior Programmierern, einem Senior Tester, einem Junior Tester, einem guten Designer und einem Datenbank-Spezialisten kann dieses Projekt in X Sprints fertig bekommen.”

Je nachdem wie Sie die Besetzung im Endeffekt wirklich vornehmen, können Sie die Einschätzung noch anpassen. Wenn z. B. weniger Senior Programmierer und dafür mehr Junior Programmierer dabei sein werden, senken Sie die Velocity ein wenig nach Ihrem fachmännischen Ermessen.

Es kann hilfreich sein, die Daten von anderen agilen Teams zu nutzen und dadurch einen gewissen Spielraum für die Bewertung zu bekommen. Berechnen Sie dafür den relativen Variationskoeffizienten (in Prozent) für die Velocity dieser anderen Teams. Anschließend errechnen Sie den durchschnittlichen Variationskoeffizienten aller Teams. Nehmen wir an, es gäbe Teams mit 15 Prozent, 20 Prozent und einige mit 25 Prozent. Der Durchschnittswert liegt dann bei +/- 20 Prozent. Nehmen Sie diesen Wert für Ihr neues Team. Wenn die Teammitglieder ihre Velocity mit 20 einschätzen, können Sie einfach +/- 20 Prozent hinzufügen.

In den meisten Fällen ziehe ich von der eingeschätzen Velocity aber 40 Prozent ab, schließlich weiß ich, dass die meisten Teams sich gerne überschätzen.