Jedes produktive Softwareentwicklungsteam verfolgt seine Verbesserungen anhand einer Reihe ausgewählter Indikatoren, die KPI-Entwicklungsmetriken genannt werden. Dies sind die 5 wichtigsten Key Performance Indicator (KPI)-Entwicklungsmetriken, mit deren Verfolgung Sie noch heute beginnen sollten.

Haben Sie jemals in einem Entwicklungsteam gearbeitet, in dem keine KPI-Metriken gemessen wurden? Wenn ja, dann wissen Sie wahrscheinlich, wie schwer es ist, festzustellen, ob das Team auf dem richtigen Weg zur Veröffentlichung ist oder nicht.

Wenn Sie Ihre Geschäftsziele erreichen wollen, müssen Sie sicherstellen, dass Ihre Software alle Anforderungen erfüllt. Um dies zu erreichen, müssen Sie technische KPI-Metriken in die Entwicklungsprozesse einführen.

Indem Sie technische KPI-Metriken für Ihr Softwareentwicklungsteam einrichten, vermeiden Sie schlechte Qualität und verpasste Termine. Das Ergebnis ist ein produktives Team und ein hochwertiges Produkt.

Hier sind fünf wesentliche KPI-Entwicklungsmetriken, die Sie verfolgen sollten, um Ihre Geschäftsziele zu erreichen.

Sprint Burndown

Was ist ein Sprint Burndown?

Agile Teams organisieren ihre Entwicklung in Sprints. Ein Sprint Burndown misst, wie viel Arbeit das Team während eines Sprints erledigt hat.

Was sind die Vorteile?

• Ein Sprint Burndown ist hervorragend geeignet, um das Team auf auftretende Hindernisse aufmerksam zu machen.
• Durch die Messung des Sprint Breakdowns können Sie überprüfen, ob Ihr Team seine Prognose erfüllt.
• Mit Hilfe eines Sprint Breakdown Diagramms kann das Team seinen Fortschritt verwalten. Wenn das Team merkt, dass es das Sprint-Ziel möglicherweise nicht erreicht, können die Teammitglieder geeignete Maßnahmen ergreifen, um auf dem richtigen Weg zu bleiben.

Wie wird es gemessen?

Agile Teams verwenden Sprint-Burndown-Diagramme, um ihren Arbeitsablauf zu visualisieren. Das Diagramm hat eine x-Achse, die die Zeit darstellt, und eine y-Achse, die die Menge der noch zu erledigenden Arbeit darstellt. Sie können die Zeit in Stunden oder Story Points messen. Sie können sich aber auch Ihre eigenen Statistiken ausdenken. Das Hauptziel besteht darin, die gesamte prognostizierte Arbeit bis zum Ende des Sprints fertig zu stellen.

Ein Tool, das Sie verwenden können, ist das Jira Sprint Breakdown Chart. Um es zu verwenden, müssen Sie ein Jira Software-Konto und ein Jira Software-Scrum-Projekt erstellen.

Sie sehen eine vertikale Achse, die Story-Punkte darstellt. Die horizontale Achse zeigt die Zeit an. Die rote Linie im Diagramm stellt die Menge an Arbeit dar, die im Sprint noch übrig ist. Die graue Linie ist die eigentliche Arbeitslinie. Wenn die rote Linie unter der grauen Linie liegt, bedeutet dies, dass das Team auf Kurs ist. Wenn die rote Linie jedoch über der grauen Linie liegt, bedeutet dies, dass das Projekt hinter dem Zeitplan zurückliegt.

Release Burndown

Was ist Release Burndown?

Release Burndown bietet einen Überblick über den Release-Fortschritt. Er ähnelt dem Sprint Burndown, ist aber von größerem Umfang. Er hilft den Teams zu überprüfen, ob sie es schaffen werden, das Produkt bis zu einem bestimmten Datum zu veröffentlichen. Wenn sie feststellen, dass sie mit dem Zeitplan in Verzug sind, können sie die Benutzer und Stakeholder über die Verzögerung informieren. Wenn nicht, können sie den Arbeitsumfang reduzieren, um das Produkt rechtzeitig zu veröffentlichen.

Was sind die Vorteile?

• Sie können überprüfen, wie schnell Ihr Team das Backlog abarbeitet.
• Sie erhalten einen Einblick, wie sich hinzugefügte und entfernte Arbeiten auf den Fortschritt Ihres Teams auswirken.
• Machen Sie Vorhersagen darüber, wie viele Sprints Ihr Team benötigen wird, um die Arbeit abzuschließen.

Wie messen Sie es?

Der Release Burndown wird mit einem Diagramm gemessen, das dem Sprint Breakdown Chart ähnelt. Der Unterschied besteht darin, dass jetzt die horizontale Achse die Sprints darstellt und die vertikale Achse die verbleibende Arbeit (Tage, Stunden oder Story Points).

Schauen wir uns zum Beispiel das folgende Bild an. Es handelt sich um ein Jira Release Burndown-Diagramm. Sie können sehen, dass das Team zunächst vier Sprints und 43 Story Points festgelegt hat. Im Laufe dieser vier Sprints hat das Team die Anzahl der Storys von 43 auf 26 reduziert. Das Team hat auch vorhergesagt, dass die Veröffentlichung des Produkts sieben weitere Sprints in Anspruch nehmen wird, was insgesamt 11 ergibt.

Zykluszeit

Was ist Zykluszeit?

Die Zykluszeit ist eine KPI-Entwicklungsmetrik, die misst, wie viel Zeit das Team mit einer Aufgabe verbringt. Zykluszeitdiagramme werden von Scrum Masters und Product Ownern verwendet, um die Effizienz des Entwicklungsprozesses zu kontrollieren.

Was sind die Vorteile?

• Sie liefert Informationen über die Gesamtleistung des Teams.
• Sie ermöglicht eine Schätzung der Fertigstellung zukünftiger Aufgaben.
• Sie können Engpässe und Verlangsamungen im Arbeitsablauf feststellen.

Wie wird sie gemessen?

Die Zykluszeit ist gleich dem Enddatum minus dem Startdatum. Wenn das Team beispielsweise am 1. Dezember mit der Arbeit beginnt und sie am 10. Dezember beendet, dann beträgt die Zykluszeit neun Tage.

Wenn das Team am 1. Dezember mit der Arbeit beginnt und die Aufgabe noch am selben Tag abschließt, ist die Zykluszeit nicht null, sondern eins. Bei Projekten, die am selben Tag beginnen und enden, ist die Zykluszeit gleich dem Enddatum minus dem Startdatum +1.

Sie können Tage durch Wochen, Stunden oder sogar Sprints ersetzen.

Verwenden Sie Zykluszeitdiagramme, um Ihren Arbeitsablauf zu visualisieren. Diese Diagramme zeigen, wie lange ein Vorgang im Vergleich zum Tag der Fertigstellung gedauert hat.

Betrachten wir zum Beispiel das folgende Diagramm. Auf der x-Achse sehen Sie das Datum, an dem die Aufgabe abgeschlossen wurde, und auf der y-Achse sehen Sie die aufgewendete Zeit. Die grünen Kreise sind Aufgaben. Ein ausgefüllter Kreis zeigt eine Gruppe von Aufgaben an, während ein offener Kreis eine einzelne Aufgabe anzeigt. Wenn Sie ein Tool wie Jira verwenden, können Sie den Schlüssel der Aufgabe, ihren Code und die Vorlaufzeit sehen, indem Sie mit der Maus über den Kreis fahren. Die rote Linie steht für die durchschnittliche Durchlaufzeit und die blaue Linie für die rollierende durchschnittliche Durchlaufzeit.

Das Endziel ist, dass das Team konsistente Zykluszeiten für Arbeitsaufgaben hat, die ähnliche Story Point-Werte haben. Niedrigere Werte bedeuten, dass das Team effizient arbeitet, während höhere Werte auf Engpässe im Arbeitsprozess hinweisen können.

Team Velocity

Was ist Team Velocity?

Velocity ist eine weitere agile KPI-Engineering-Metrik, die die Arbeitsmenge misst, die ein Team während eines Sprints erledigt. Der Arbeitsaufwand wird normalerweise in Story Points oder Stunden gemessen.

Produktverantwortliche verwenden Velocity, um zu berechnen, wie schnell ein Team das Backlog abarbeiten kann. Der Velocity-Index ist für jedes Team einzigartig, und Sie sollten die Velocity nicht mit anderen Teams vergleichen.

Angenommen, Sie wollen 300 Story Points im Backlog abarbeiten. Sie wissen, dass das Entwicklungsteam im Durchschnitt etwa 50 Story Points pro Iteration abschließt. Mit diesen Informationen können Sie vorhersagen, dass das Team sechs Iterationen benötigt, um die erforderliche Arbeit abzuschließen.

Was sind die Vorteile?

• Es ist sehr nützlich für Prognosen.
• Es kann bei der Planung zukünftiger Sprints helfen.
• Es kann Ihnen helfen zu verstehen, ob das Team blockiert ist oder ob Ihre Prozessänderungen funktionieren.

Wie messen Sie es?

Wenn Sie ein stabiles Team haben, können Sie eine durchschnittliche Geschwindigkeit ermitteln, indem Sie mindestens 5-7 Sprints messen. Wenn Ihr üblicher Sprint wöchentlich stattfindet und das Team 250 Story Points über einen Zeitraum von fünf Wochen fertigstellt, dann beträgt Ihre durchschnittliche Velocity-Rate 50 Story Points pro Woche.

Werfen wir einen Blick auf das Jira Velocity Chart unten. Die blauen Balken stehen für das Engagement und die grünen Balken für die tatsächlich geleistete Arbeit. In Sprint Nummer 1 hat das Team 16 Story Points geplant und 16 Story Points abgeschlossen. Dies zeigt, dass die Schätzungen korrekt waren. Im zweiten Sprint plante das Team jedoch 19 Story-Points, schloss aber nur 12 ab. Dies deutet darauf hin, dass sie beim nächsten Mal ihren Plan reduzieren sollten.

Ein inkonsistenter Fluss ist ein Indikator dafür, dass Sie Probleme in der Entwicklung haben und Änderungen vornehmen müssen.

Kumulativer Fluss

Was ist kumulativer Fluss?

Der kumulative Fluss visualisiert den Status Ihrer Tickets über einen bestimmten Zeitraum. Er zeigt die Verschiebung Ihrer Tickets von einem Status zu einem anderen, während Ihr Projekt fortschreitet.

Was sind die Vorteile?

• Es ist nützlich für die Identifizierung von Engpässen.
• Hilft Teams sicherzustellen, dass der Arbeitsfluss konsistent ist.
• Es zeigt Ihnen, wie stabil Ihr Workflow ist.
• Es hilft Ihnen zu verstehen, wie Sie Ihren Prozess vorhersehbarer machen können.

Wie messen Sie ihn?

Am einfachsten lässt sich der kumulative Arbeitsablauf anhand von Diagrammen messen. Sie visualisieren die drei wichtigsten Software-Engineering-Kennzahlen Ihres Workflows, darunter Zykluszeit, Durchsatz und laufende Arbeit.

Betrachten wir das folgende Diagramm. Die horizontale x-Achse zeigt die Zeit an, während die vertikale y-Achse die Arbeitspunkte anzeigt. Die verschiedenen Farben stehen für die verschiedenen Zustände des Arbeitsablaufs. Wenn die Bänder parallel verlaufen, bedeutet dies, dass Ihr Durchsatz stabil ist. Es zeigt an, dass die Anzahl der neuen Aufgaben, die in Ihren Workflow eintreten, der Anzahl derer entspricht, die ihn verlassen.

Wenn sich ein Band schnell verengt, bedeutet dies, dass Sie mehr Kapazität haben, als Sie benötigen. Sie sollten die Kapazität verlagern, um den Fluss zu optimieren.

Wenn sich ein Band schnell verbreitert, bedeutet dies, dass mehr Karten in die entsprechende Phase eintreten als es Aufgaben gibt, die sie verlassen.

Summing Up

Die Verfolgung der oben beschriebenen KPI-Entwicklungsmetriken kann zu einem erfolgreichen Ausgang des Produktentwicklungsprozesses führen. Sie können aufhören, den Fortschritt Ihres Projekts zu hinterfragen, und erhalten einen detaillierten Einblick in jede Phase des Entwicklungslebenszyklus.

Wenn Sie dem Teufelskreis aus minderwertigen Produkten, verpassten Terminen und fehlerhaftem Code ein Ende setzen wollen, beginnen Sie noch heute mit der Implementierung von KPI-Entwicklung. Es wird Ihnen gelingen, ein erstklassiges Produkt ohne die damit verbundenen Risiken zu veröffentlichen.