Vom Excel-Flickenteppich zum Agile KPI Dashboard

In der Organisation gab es viele Delivery-Daten und erstaunlich wenig gemeinsame Transparenz.

Die Informationen waren über eine alte On-Premise-Jira-Instanz, Excel-Dateien und Microsoft Forms verteilt. Teams verwendeten unterschiedliche Vorlagen und teilweise unterschiedliche Auslegungen derselben KPI. Ein Gesamtbild entstand nur durch manuelles Sammeln, Kopieren und Abgleichen. Wenn der Bericht fertig war, waren einzelne Teile bereits wieder veraltet.

Ich wollte eine konsistente Sicht darauf schaffen, wie sich die agilen Teams und SAFe-Teams über die Zeit entwickeln, ohne ein weiteres Reporting-Ritual einzuführen.

Ein unglaublich schneller Prototyp

Die Geschwindigkeit der ersten funktionsfähigen Version hat mich selbst überrascht. Mit KI-Unterstützung konnte ich das nächste gewünschte Ergebnis beschreiben, den erzeugten React- und TypeScript-Code prüfen, die Anwendung starten und direkt korrigieren. Diese Feedbackschleife dauerte häufig Minuten statt der langen Aufbauzyklen, die ich aus klassischen Projekten kannte.

Teamübersicht, Sprint-Detail, Archiv, Konfiguration und Berichtsassistent entstanden in solchen kurzen Iterationen. Die KI übernahm einen großen Teil des Grundgerüsts und wiederkehrender UI-Arbeit. Die Produktentscheidungen blieben bei mir: Welche Kennzahlen gehören zusammen? Wie sollen Trends eingeordnet werden? Was braucht das Datenmodell? Und wo muss die Sicherheitsgrenze verlaufen?

Diese Trennung war entscheidend. Schnelle Generierung machte mehr Experimente möglich, ersetzte aber nicht die Prüfung der Ergebnisse. Der AgileMetrics-Quellcode auf GitHub macht die Umsetzung nachvollziehbar, statt sie hinter dem Prototyp zu verstecken.

Was das Dashboard zeigt

Die Übersicht führt aktuellen Durchsatz, Cycle Time und Kapazität aller Teams zusammen. Trendindikatoren vergleichen den aktuellen Sprint mit seinem Vorgänger. In der Teamansicht kommen Sprint-Ziel und Zielerreichung, Lead Time, Release-Häufigkeit, Burndown und Sprint-Historie hinzu.

Der technische Stack bleibt bewusst kompakt:

• React 19, TypeScript und Tailwind CSS 4 für die responsive Anwendung.
• Recharts, Motion und Lucide React für Visualisierung und Interaktion.
• Node.js und Express für die REST-API.
• Better-SQLite3 für lokale Team- und Sprint-Historien.
• Vite für Entwicklung und Produktions-Build.

Die öffentliche Version enthält Demodaten und einen Berichtsassistenten. Dadurch lässt sich die Anwendung ohne interne Unternehmensdaten ausprobieren. Das Produktivkonzept verbindet dasselbe Datenmodell mit Jira.

Jira anbinden, ohne Jira zu öffnen

Eine direkte Browser-Verbindung zur alten On-Premise-Jira-Instanz hätte unnötige Sicherheitsrisiken geschaffen. Dafür wären möglicherweise neue eingehende Zugriffe, weitreichende API-Rechte oder Zugangsdaten an ungeeigneten Stellen nötig gewesen.

Stattdessen arbeitet ScriptRunner nach einem erfolgreich abgeschlossenen Sprint innerhalb von Jira. Der Prozess wählt nur die freigegebenen Felder aus, bereitet die benötigten KPI-Werte auf und erzeugt einen definierten JSON-Snapshot. Dieser passt zum Sprint-Datenmodell des Dashboards und kann über die API der Anwendung gespeichert werden.

Die Grenze ist einfach und überprüfbar:

• Keine Jira-Zugangsdaten oder administrativen Tokens gelangen in den Browser.
• Jira benötigt keine öffentliche eingehende Verbindung vom Dashboard.
• Der Export enthält nur die für das Reporting erforderlichen Daten.
• Beschreibungen, Kommentare und unnötige personenbezogene Daten bleiben in Jira.
• Jeder abgeschlossene Sprint erzeugt einen stabilen historischen Datensatz statt einer veränderlichen Live-Abfrage.

Auch eine JSON-Datei braucht einen freigegebenen Speicherort, Zugriffsschutz und eine Aufbewahrungsregel. Ihr Vorteil liegt darin, dass die Organisation genau nachvollziehen kann, welche Daten die Systemgrenze überschreiten.

Was sich dadurch verändert

Das Dashboard ersetzte mehrere konkurrierende Berichtssichten durch eine gemeinsame Sprache. KPI-Definitionen wurden wiederholbar, und jede Zahl ließ sich einem konkreten Sprint-Bericht zuordnen.

Gleichzeitig sank der manuelle Aufwand. Teams mussten denselben Bericht nicht länger in einer weiteren Tabelle nachbauen. Die Reporting-Zeit konnte für die Diskussion von Mustern genutzt werden, statt Formeln und kopierte Werte zu kontrollieren.

Die historische Sicht machte Entwicklungen leichter erkennbar. Ein schwieriger Sprint kann ein Ausreißer sein. Wiederholte Veränderungen bei Durchsatz, Cycle Time oder Sprint-Zielerreichung verdienen eine genauere Betrachtung. Zeigen mehrere Teams dasselbe Muster, liegt die Ursache möglicherweise in Abhängigkeiten, gemeinsam genutzten Plattformen oder Entscheidungswegen und nicht innerhalb eines einzelnen Teams.

Vor allem schafft das Dashboard Transparenz, ohne so zu tun, als könne eine einzelne Zahl Agilität messen. Es ist ein Gesprächswerkzeug für Teams, Product Owner, Scrum Master und Führungskräfte. Der eigentliche Wert entsteht, wenn ein sichtbares Muster zu einer besseren Frage, einer Entscheidung oder einem Experiment führt.

KI hat den Prototyp unglaublich schnell gemacht. Das nützliche Produkt entstand aus der Verbindung dieser Geschwindigkeit mit klaren KPI-Definitionen, technischer Prüfung und einer sicherheitsbewussten Integration in die vorhandene Umgebung.

Der Teil, der nie in Produktion ging

Das Dashboard ging nie in Produktion. Der Grund ist einfach: Es war zu schnell, zu gut und hätte in einem konservativen, langsamen deutschen Unternehmen zu viel verändert. :)

Das Dashboard ist nicht gescheitert. Es funktionierte schneller, als die Organisation bereit war, sich zu verändern.

Das ist die bewusst zugespitzte Version. Die ernstere Erkenntnis dahinter: Ein funktionierendes Produkt kann etablierte Reporting-Routinen, Zuständigkeiten und Entscheidungswege schneller infrage stellen, als eine Organisation bereit ist, sie zu verändern. Die technische Lösung war tragfähig. Die Organisation war noch nicht bereit für ihre Konsequenzen.