Engineering-Metriken ohne Jira
Du brauchst kein Jira, um das Wesentliche zu messen. So verfolgst du Engineering-Gesundheit aus Git, CI und den Tools, die dein Team bereits nutzt.
By Ellis Keane · 2026-03-23
Kleine Teams mit der besten Engineering-Sichtbarkeit sind oft genau die, die aufgehört haben, den Metriken nachzujagen, die Jira von ihnen verlangt.
Ich weiß, das klingt nach purem Widerspruch um des Widerspruchs willen – und ehrlich gesagt liegt da vielleicht ein Körnchen Wahrheit drin. Aber ich habe fast drei Jahre damit verbracht, gewissenhaft Sprint-Boards zu pflegen, Backlogs zu verfeinern und Schätzungen auf Tickets zu aktualisieren, die schon halb fertig waren, bevor irgendjemand an dem Morgen Jira geöffnet hatte. Alle zwei Wochen saßen wir in einem Raum (nun ja, einem Zoom-Meeting – es war 2023) und starrten auf ein Velocity-Chart, das uns exakt nichts verriet, was wir nicht ohnehin schon aus Gesprächen miteinander wussten. Engineering-Metriken ohne Jira war nichts, wonach ich aktiv gesucht hatte. Es war das Ergebnis, als ich aufhörte, so zu tun, als würden mir Velocity-Charts irgendetwas Nützliches sagen.
Wenn dein Team klein genug ist, um an einem Tisch zu sitzen, brauchst du wahrscheinlich kein Jira, um zu wissen, wie ihr dasteht. Du brauchst bessere Signale aus Tools, die du ohnehin schon verwendest.
Das hier ist kein „Jira ist schlecht"-Beitrag. Jira ist ein durchaus gutes Tool für Organisationen, die Jira-ähnliches Tracking benötigen (und ab einer bestimmten Größe brauchen sie es tatsächlich). Aber wenn du als Engineering Manager eines 10- bis 40-köpfigen Startups für Jira allein bezahlst, um Velocity-Charts zu erzeugen, ist das ein bisschen so, als würdest du einen Industrieofen kaufen, um dein Mittagessen aufzuwärmen.
„Für Jira allein zu bezahlen, um Velocity-Charts zu erzeugen, ist ein bisschen so, als würdest du einen Industrieofen kaufen, um dein Mittagessen aufzuwärmen." attribution: Chris Calo
Was Jira-Metriken wirklich messen
Lass mich direkt sein: Die meisten Jira-Metriken messen die Nutzung von Jira, nicht den Engineering-Output. Story Points messen die Fähigkeit des Teams, Story Points zu schätzen. Velocity misst, wie konsequent das Team Sprints auf ungefähr die gleiche Kapazität füllt. Burndown-Charts messen, ob jemand daran gedacht hat, am Donnerstagnachmittag Tickets übers Board zu ziehen.
Keine davon ist völlig nutzlos. Aber sie sind Prozessmetriken, die als Entwicklerproduktivitätsmetriken verkleidet sind – und genau in dieser Lücke verlieren Engineering Manager den Überblick.
Ich war selbst der EM, der kurz vor einem Stakeholder-Meeting fast eine Stunde damit verbracht hat, Jira-Daten in eine Präsentation zu massieren, die zeigt: „Wir sind auf Kurs." Der Stakeholder nickt, stellt eine Frage zum Login-Bug von letztem Dienstag, und das Meeting endet. Die Stunde war für die Präsentation. Die eigentliche Antwort war: „Frag den Ingenieur."
Wenn deine Metriken mehr Pflege erfordern als die Arbeit, die sie messen, sind die Metriken das Problem.
Cycle Time aus Git, nicht aus Ticket-Boards
Für kleine Produktteams ist die Cycle Time in der Regel die Metrik mit dem höchsten Signal, die man verfolgen kann. Sie misst die Dauer vom ersten Commit bis zum Production-Deploy und lässt sich vollständig aus der Git-Historie und CI-Pipeline ableiten – kein Ticket-Board erforderlich.
Die Komponenten:
- Erster Commit-Zeitstempel auf einem Branch oder PR
- PR-Merge-Zeitstempel
- Deploy-Zeitstempel (aus deinem CI/CD – GitHub Actions, CircleCI oder was auch immer du verwendest)
Das Delta zwischen 1 und 3 ist deine Cycle Time. Unterteile sie in Segmente – Coding-Zeit (1 bis PR-Öffnung), Review-Zeit (PR-Öffnung bis Merge) und Deploy-Queue (Merge bis Production) – und du hast eine Diagnose, die dir zeigt, wo die Arbeit tatsächlich ins Stocken gerät.
Als ich das zum ersten Mal für unser Team durchführte, waren die Zahlen wirklich überraschend. Ich hatte angenommen, Review-Zeit sei unser Engpass (das nimmt jeder immer an, oder?). Es stellte sich heraus: Unsere Coding-bis-PR-Phase war in Ordnung, Reviews waren in Ordnung, und wir verloren im Durchschnitt etwa zwei Tage zwischen Merge und Deploy, weil unsere Staging-Umgebung instabil war und niemand die Behebung priorisiert hatte. Ein Velocity-Chart hätte das niemals aufgedeckt.
So misst du es
Wenn du GitHub nutzt, kannst du es mit der CLI abfragen:
```bash
Zusammengeführte PRs der letzten 30 Tage abrufen
gh pr list – state merged – limit 50 – json number,createdAt,mergedAt,headRefName ```
Für Deploy-Zeitstempel stellen die meisten CI-Systeme diese per API oder Webhook bereit. Ordne PR-Merge-SHAs den Deploy-Events zu, und du hast die Cycle Time segmentiert nach Phase.
Tipp: Wenn dein CI keine sauberen Deploy-Zeitstempel liefert, ist ein denkbar einfacher Ansatz ein Slack-Bot, der mit dem Commit-SHA in einen #deploys-Kanal postet. Du erhältst Zeitstempel, ein menschenlesbares Log und – als Nebeneffekt – einen Kanal, der dir zeigt, wie oft ihr liefert.
Code-Review-Durchsatz
Review-Durchsatz – die Anzahl der pro Ingenieur und Woche überprüften PRs sowie die mittlere Zeit vom PR-Öffnen bis zum ersten Review – sagt mehr über die Team-Gesundheit aus als jede Sprint-Metrik. Er wird unterschätzt.
Warum? Weil Review-Verhalten ein vorlaufender Indikator ist. Wenn Review-Zeiten steigen, bedeutet das meist, dass Ingenieure überlastet sind, zu stark den Kontextwechsel betreiben oder – und das ist der unbequeme Teil – den Code des anderen meiden. Jedes dieser Szenarien ist es wert, davon zu erfahren, bevor es zwei Wochen später als verpasste Deadline auftaucht.
GitHub liefert diese Daten über seine API. Die wichtigsten Felder sind createdAt beim PR und submittedAt beim ersten Review-Event.
Die Zahl, die ich beobachte, ist die mittlere Stunden bis zum ersten Review. Unserer Erfahrung nach in einigen kleinen Teams liegt eine gesunde Review-Kadenz üblicherweise unter etwa 8 Stunden. Wenn sie dauerhaft über einen Tag steigt, hat sich etwas Strukturelles verändert – und was auch immer es ist, in Jira ist es unsichtbar.
Das Meetings-zu-Entscheidungen-Verhältnis
Das ist keine traditionelle Engineering-Metrik, und ich sollte offen sein: Es ist eine grobe Heuristik, kein KPI. Aber für kleine Teams finde ich sie überraschend aufschlussreich.
Zähle die Meetings deines Teams diese Woche. Zähle die konkreten Entscheidungen, die dabei herausgekommen sind (nicht „wir sollten X untersuchen" – echte Entscheidungen mit Verantwortlichen und nächsten Schritten). Dividiere letzteres durch ersteres.
Wenn weniger als die Hälfte deiner Meetings zu einer Entscheidung geführt hat, lohnt es sich zu fragen, ob diese Meetings ihre Zeit rechtfertigen. Manche Meetings existieren, um Risiken zu reduzieren oder Kontext zu teilen – das ist legitim, nicht alles muss mit einer Lösung enden. Aber wenn du das auch nur informell verfolgst (ich habe buchstäblich einen Strich in meinem Notizbuch geführt), entwickelst du ein Gespür dafür, welche Meetings produktiv sind und welche nur Rituale sind, die niemand hinterfragt hat.
Ich habe das etwa einen Monat lang verfolgt, und es hat meine Meeting-Planung mehr verändert als jeder Produktivitätsartikel. Wenn du sehen kannst, dass dein montäglicher Standup in drei aufeinanderfolgenden Wochen exakt null Entscheidungen hervorgebracht hat, wirkt das Absagen nicht mehr radikal.
Engineering-Metriken ohne Jira: ein leichtgewichtiges Dashboard
Du brauchst kein BI-Tool dafür. Eine Notion-Seite, ein Google Sheet oder ein wöchentlicher Slack-Post mit vier Zahlen genügt:
- Mittlere Cycle Time (aus Git/CI) – liefern wir schneller oder langsamer?
- Mittlere Zeit bis zum ersten Review (aus GitHub) – überprüft das Team zeitnah?
- Deployment-Häufigkeit (aus CI oder #deploys-Kanal) – wie oft liefern wir?
- Meetings-zu-Entscheidungen-Verhältnis (manuelle Zählung) – rechtfertigen unsere Meetings ihren Aufwand?
Vier Zahlen, alle aus bereits vorhandenen Tools ableitbar, ohne Pflege eines Jira-Boards. Wöchentlich aktualisieren. Bewegt sich eine Zahl zwei Wochen in Folge in die falsche Richtung, untersuche es. Bleibt sie stabil, lass sie in Ruhe.
Der Punkt ist nicht, ein Überwachungssystem zu bauen (bitte tue das nicht – deine Ingenieure werden dich dafür hassen, und sie hätten Recht damit). Engineering-Team-Sichtbarkeit sollte aus der Arbeit selbst kommen, nicht daher, dass man Menschen bittet, über die Arbeit zu berichten.
Die besten Engineering-Metriken sind günstig zu erheben, schwer zu manipulieren und sagen dir etwas, auf das du reagieren kannst. Story Points scheitern an allen drei Punkten.
Wann du tatsächlich ein Ticket-Board brauchst
Ich sagte, das ist kein „Jira ist schlecht"-Beitrag, und das meinte ich so. Es gibt legitime Situationen, in denen das Verfolgen von Metriken ohne ein Projektmanagement-Tool wirklich unverantwortlich wird:
- Compliance-intensive Branchen, in denen Audit-Trails zum Aufgabenstatus gesetzlich vorgeschrieben sind
- Größere Engineering-Organisationen, bei denen teamübergreifende Abhängigkeiten informelle Koordination unhaltbar machen
- Organisationen mit dedizierten Projektmanagement-Funktionen, die eine kanonische Informationsquelle über Teams hinweg benötigen
Wenn das deine Situation ist, ist Jira (oder Linear oder Shortcut) die richtige Wahl. Was ich argumentiere: Für kleine Teams ist es ein schlechter Tausch, ein schweres Tool allein für Metriken zu pflegen. Man optimiert am Ende für das Arbeitsmodell des Tools anstatt für die tatsächliche Arbeit des Teams.
Und ehrlich gesagt? Selbst Teams, die Jira nutzen, würden davon profitieren, ihre Board-Daten mit den oben genannten Git-basierten Metriken zu ergänzen. Jira sagt dir, was die Leute sagen, was sie tun. Git sagt dir, was sie tatsächlich tun. Beides ist nützlich, aber nur eines ist immun gegen Status-Update-Theater.
Wenn die Metrik-Frage in deinem Startup immer wieder auftaucht, probiere das Vier-Zahlen-Dashboard einen Monat lang. Engineering-Metriken ohne Jira klingt vielleicht wie das Arbeiten ohne Sicherheitsnetz – aber sobald du siehst, wie viel Signal in deiner Git-Historie und CI-Pipeline steckt, wirst du dich fragen, was das Ticket-Board eigentlich beigetragen hat.
Cycle Time, stockende PRs und Review-Engpässe automatisch aufdecken – ohne eigene Skripte oder ein Jira-Board.
Q: Kann man aussagekräftige Engineering-Metriken ohne ein Projektmanagement-Tool erhalten? A: Ja. Cycle Time (erster Commit bis Deploy), Review-Durchsatz und Deployment-Häufigkeit liegen alle in deiner Git-Historie und CI-Pipeline. Für Teams unter etwa 40 Ingenieuren sind diese in der Regel schärfer und schwerer zu manipulieren als alles, was ein Ticket-Board erzeugt – und sie erfordern nicht, dass jemand Karten über ein Board zieht, um aktuell zu bleiben.
Q: Zeigt Sugarbug Engineering-Metriken automatisch an? A: Sugarbug verbindet sich mit GitHub, Linear, Slack und Kalendern, um einen Wissensgraph der Teamaktivitäten aufzubauen. Es markiert Muster wie stockende PRs, Review-Engpässe und ungelöste Entscheidungen – was viele der hier beschriebenen Signale abdeckt, ohne dass du eigene Skripte gegen die GitHub-API schreiben und pflegen musst.
Q: Wie bekomme ich Zustimmung, Jira nicht mehr für Metriken zu nutzen? A: Rahme es als Experiment, nicht als Revolte. Führe Git-basierte Metriken vier Wochen lang neben deinen bestehenden Jira-Dashboards, und vergleiche dann, welche Zahlen tatsächliche Änderungen angestoßen haben. Wenn die Git-Metriken sich als handlungsrelevanter erweisen (und unserer Erfahrung nach tun sie das), macht sich der Fall von selbst.
Q: Was ist der Unterschied zwischen Prozessmetriken und Leistungsmetriken? A: Prozessmetriken (Story Points, Velocity, Burndown) messen, wie konsequent ein Team einem Workflow folgt. Leistungsmetriken (Cycle Time, Deployment-Häufigkeit, Review-Durchsatz) messen, was das Team tatsächlich liefert und wie schnell. Kleine Teams bekommen fast immer mehr Signal aus letzteren, weil Leistungsmetriken aus der Arbeit selbst abgeleitet werden und nicht aus manuellen Status-Updates.