Gestern hatte ich gefragt, wie man kurzfristig die Velocity steigern kann, ohne dabei das Gesamtergebnis (gelieferten Business Value) besser zu machen. Mit dem Hintergedanken, dass Controller und Gleichgesinnte sich gern auf Metriken und KPIs stürzen, um “die Performance” zu verbessern.

Zum Hintergrund: Ein “Story Point” ist eine willkürlich gewählte Einheit, in der die Entwickler den Aufwand schätzen. Velocity (“Entwicklungsgeschwindigkeit”) wird berechnet als “Story Points pro Zeiteinheit”. Wenn ein Team also in einer zweiwöchigen Iteration 40 Story Points abgearbeitet hat, dann sagen wir “Velocity ist 20 Story Points pro Woche”. Wenn es in der nächsten Iteration z.B. einen Arbeitstag (10%) weniger gibt, dann nehmen wir uns eben nur 36 Story Points vor. So kann man ungefähr abschätzen, wie lange eine gewisse Menge von Features o.ä. dauern wird.

Hier sind einige Möglichkeiten, wie das Bewerten von Teams mit der Metrik “Velocity” unterlaufen werden kann.

1. Großzügiger schätzen. Das geht eigentlich immer: die Story Points werden ja weitgehend subjektiv vergeben, niemand hindert uns daran, in der nächsten Runde ein paar mehr Punkte zu verteilen. Falls das ganze Backlog am Anfang geschätzt wurde, müssen wir die Story-Point-Inflation halt mit neu aufgetauchten Stories machen. Bugs sind eine weitere Gelegenheit zum großzügigeren Schätzen.
2. Die Qualität runterschrauben. Ich kann als Entwickler die Story für “fertig” erlären, obwohl vielleicht nicht alle Spezialfälle berücksichtigt sind. Ich kann auch stur die Spezifikation umsetzen, ohne mich um Spezialfälle zu kümmern, die ich gerade entdeckt habe. Sollen die anderen doch darauf kommen, irgendwann.
3. Code-Qualität verringern. Irgendwas aufräumen? Bringt keine Punkte, also lasse ich es. Mag sein, dass wir damit langfristig langsamer werden, aber wenn die technischen Schulden irgendwann in der Zukunft fällig werden, kann ich ja einfach meine Schätzung etwas größer machen.
4. Anderen Teams nicht mehr helfen. Lokal optimiert jedes Team seine Velocity, dabei bleibt die Zusammenarbeit auf der Strecke.

Es muss gar kein böser Wille dahinter stecken, aber wenn man Metriken als Zuckerbrot oder Peitsche verwendet, verleitet man die Leute dazu, die Metrik bewusst oder unbewusst zu unterlaufen. Und die Metrik zu verfeinern hilft da wenig, am Ende sind Menschen immer kreativer als irgendwelche Metriken.

Was hilft? Grundsätzlich darauf vertrauen, dass die Teammitglieder kompoetent sind und ihre Sache gut machen wollen. Metriken können dafür Feedback geben, taugen aber eben nicht als Anreiz.

Matthias Berth