Obwohl die sogenannte Velocity ihren Ursprung in Extreme Programming hat, wird sie heutzutage quer durch die Bank der agilen Entwicklungsframeworks eingesetzt und kann wohl als eine der am weitest verbreiteten Metriken der agilen Softwareentwicklung angesehen werden.
Gleichzeitig wird die Bedeutung der Velocity oft falsch verstanden und diese sogar missbräuchlich verwendet. Daher zeigen wir Ihnen hier, was die Velocity wirklich bedeutet und wie Sie sie zu Ihrem Vorteil einsetzen können.
Wie man die Velocity in Scrum richtig berechnet
Die Velocity gibt die Menge an neu gelieferter Software in Story Points pro Iteration (Sprint) an. Wie man Story Points richtig schätzt haben wir bereits in diesem Blogbeitrag erklärt.
Wenn ein Team beispielsweise 4 User Stories zu je 5 Story Points im Sprint erfolgreich umgesetzt hat, dann war die Velocity für diesen Sprint gleich 20 Story Points pro Sprint.
Wichtig ist hier, dass nur vollständig gemäß Definition of Done umgesetzte Story Points zur Velocity beitragen und unfertige somit niemals zur Velocity beitragen, auch nicht teilweise.
Wie formuliert man User Stories richtig?
8 Punkte, die Sie bei der Erstellung beachten sollten!
Was bedeutet Velocity und welchen Nutzen hat sie?
Man kann Velocity also tatsächlich als eine Art Geschwindigkeit betrachten, die von zahlreichen Faktoren beeinflusst wird.
"Die Velocity dient dem Sinn und Zweck Softwareentwicklungs-Vorhaben planbar zu machen."
Ein eingespieltes Scrum Entwicklungsteam entwickelt mit der Zeit eine relativ konstante Velocity – man weiß also, dass man eine gewisse Velocity pro Sprint erwarten kann. Geringfügige Abweichungen davon wirken sich in der Regel kaum merkbar auf eine langfristige Planung aus.
Ein neues Team sollte hingegen erst einige Sprints zusammenarbeiten, bevor deren Velocity für eine Planung herangezogen wird.
Gehen wir nun von obigem Beispiel aus, und das Team liefert im Durchschnitt 20 Story Points pro Sprint, so lässt sich ganz einfach berechnen, wie viele Story Points über einen längeren Zeitraum erwartet werden können. Bei einem Zeitraum von 10 Sprints wären wir somit bei etwa 200 Story Points. Wenn Sie nun die Kosten für einen Sprint kennen, können Sie ganz einfach berechnen, wie viele Story Points für Ihr Investment geliefert werden.
Mit dieser Info können Sie nun in Ihrem Product Backlog so priorisieren, dass Sie mit Ihrem Investment möglichst viel werthaltige Software erhalten. Sie können also selbst anhand einfacher Mittel steuern, wofür Ihr Budget tatsächlich aufgewandt wird und behalten so die Kontrolle über die Maximierung des Return on Investment – und das über die gesamte Entwicklungszeit hinweg.
Die Velocity zeigt die Performance des Teams an?
Wie schon erwähnt gibt die Velocity Auskunft darüber, wie viel neue Software in einem bestimmten Sprint geliefert wurde. Was auf den ersten Blick aussehen mag wie die Performance des Teams, ist durch eine Vielzahl von Faktoren beeinflußt, auf die das Entwicklerteam keinen Einfluss hat. Einige der wichtigsten sind folgende:
Störungen aller Art
Wann immer ein Team während des Sprints aus seiner Arbeit „gerissen“ wird, kann die Velocity darunter leiden. Und es mag viele Gründe geben, warum ein Team bei der Arbeit unterbrochen wird.
Technische Schulden
Sie sind ein großer Einflussfaktor, da sie dem Team viel Zeit kosten können. Das häufigste Symptom von technischen Schulden sind Fehler im Produktionsbetrieb sowie schwer wartbarer Code. Das lenkt von der eigentlichen Arbeit ab bzw. sorgt auch dafür, dass das Entwickeln neuer Features länger dauert.
Zu geringe Verfügbarkeit des Product Owners
Dies wird sich fast immer negativ auf die Velocity auswirken, da die Entwickler durch fehlende Entscheidungen blockiert sind oder auf falschen Annahmen basierend arbeiten, was zu späteren Umbauten führen wird.
Unklare Anforderungen
Der vorige Punkt wird noch verstärkt, wenn zusätzlich zur mangelnden Verfügbarkeit auch die Anforderungen so unklar sind, dass noch mehr Product Owner Präsenz gefordert ist. Auch wenn User Stories primär den Dialog fördern sollen, kann durch Klarheit die man vor allem im Sprint Planning bzw. Backlog Refinement erreicht, viel Zeit im Sprint gespart werden. Deshalb sollte der Product Owner spätestens im Sprint Planning sicherstellen, dass er von allen Entwicklern auch richtig verstanden wurde.
Grad an Automatisierung des Softwareentwicklungs- bzw. Deployment Prozesses
Ist eine vollständig automatisierte Continuous Deployment Infrastruktur vorhanden? Wird diese genutzt? Werden sämtliche Tests automatisiert? Wie ist die Branching-Strategie der Entwickler?
Abhängigkeiten zu anderen Teams
Die Zusammenarbeit mit anderen Teams kann ebenfalls die Velocity verringern, vor allem wenn das Team nicht cross-functional aufgestellt ist und für eine vollständige Lieferung den Output eines oder mehrerer anderer Teams benötigt. Daher ist es unumgänglich, dass jedes Team, welches an einem Produkt arbeitet, eigenständig ein Feature end-to-end entwickeln kann.
Daher ist die „plumpe“ Anwendung der Velocity als Schlüsselkennzahl für die Performancemessung des Entwicklerteams nicht zielführend. Vielmehr geht es darum, dass die Velocity als Maßgröße für die Menge der gelieferten Software den Ausgangspunkt zur weiteren Analyse und eines permanenten Verbesserungsprozesses (z.B.: im Zuge der Retrospektive) darstellt.
Der Vergleich bzw. die Analyse der Velocity über die Zeit (von Sprint zu Sprint) und die Frage „was hindert uns, die Velocity zu steigern?“ unter Berücksichtigung von exogenen Faktoren kommt hier wesentliche Bedeutung zu. Die grundsätzlichen Anforderungen bzw. Überlegungen im Kontext der richtigen Definition und Anwendung von Kennzahlen bzw. KPI, wie zum Beispiel der S.M.A.R.T. Formel, gilt natürlich auch bei der Velocity.
Wissen Sie, was Ihre User wirklich wollen?
Mit User Story Mapping können Sie das in 4 einfachen Schritten herausfinden!
