Engineering-Metriken & Agile-Glossar
Die Begriffe, die Engineering-Teams zum Planen, Schätzen, Messen und Verbessern verwenden — in verständlicher Sprache definiert, mit einem weiterführenden Link, wo einer in unseren kostenlosen Kursen und unserem Blog existiert.
34 Begriffe · 6 Abschnitte · Veröffentlicht Juli 2026
Lieferung & Flow
7 BegriffeZykluszeit
Die Zykluszeit ist die Zeit vom Beginn der Arbeit an einem Element bis zu dessen Fertigstellung: Die Uhr startet, wenn jemand mit dem Element beginnt, und stoppt, wenn es fertig ist. Sie misst die interne Effizienz des Teams, und ihre Schwankung ist genauso wichtig wie ihr Durchschnitt. Ein Team, dessen Elemente zwischen 3 und 5 Tagen liegen, ist weitaus berechenbarer als eines mit einer Spanne von 1 bis 30 Tagen.
Lead Time
Lead Time ist die Gesamtzeit vom Zeitpunkt der Arbeitsanforderung bis zur Auslieferung an den Kunden. Sie entspricht der Zykluszeit plus Wartezeit, und Warteschlangen machen oft 80 % oder mehr davon aus. Lead Time ist das, was Kunden erleben; Zykluszeit ist das, was das Team direkt steuert. Beides ist wichtig, und Teams, die nur die Zykluszeit sehen, unterschätzen dramatisch, wie lange die Lieferung tatsächlich dauert.
Durchsatz
Durchsatz ist die Anzahl der Arbeitselemente, die ein Team pro Zeiteinheit abschließt, zum Beispiel acht Features pro Sprint. Er misst die Ausgaberate und Kapazität eines Liefersystems. Anders als Velocity zählt Durchsatz fertige Elemente statt geschätzter Punkte, was ihn zu einer gemessenen Größe statt einer geschätzten macht.
WIP-Limit
Ein WIP-Limit ist eine Obergrenze dafür, wie viele Arbeitselemente ein Team gleichzeitig in Bearbeitung haben darf. Es ist die kontraintuitivste Kanban-Praktik: Indem man weniger gleichzeitig macht, schließt man insgesamt mehr ab, weil Little's Law die Lead Time direkt an die Menge der Arbeit im System koppelt. WIP-Limits sind Experimente, keine Berechnungen; fang irgendwo an und passe an.
Little's Law
Little's Law ist eine warteschlangentheoretische Beziehung, die 1961 von John Little bewiesen wurde und besagt, dass Lead Time gleich Work in Progress geteilt durch Durchsatz ist. Für jedes stabile System verkürzt die Reduzierung von WIP die Lead Time, ohne dass jemand schneller arbeiten muss. Ein Team, das 10 Elemente pro Woche mit 40 in Bearbeitung abschließt, braucht durchschnittlich 4 Wochen pro Element; eine WIP-Begrenzung auf 20 halbiert das auf 2.
Mehr: Little's Law: Die Mathematik des Flows (Kanban-Grundlagen)
Blocker
Ein Blocker ist alles, was ein Arbeitspaket oder eine Person daran hindert, Fortschritte zu machen: eine Abhängigkeit von einem anderen Team, ein technischer Ausfall, unklare Anforderungen, fehlende Ressourcen oder ein externer Anbieter. Blocker, die unerwähnt bleiben oder zu wenig besprochen werden, gehören zu den größten Killern von Sprint-Zielen – deshalb ist das Sichtbarmachen von Blockern der wertvollste Teil jedes Standups.
Technische Schulden
Technische Schulden sind die akkumulierten Kosten von Abkürzungen im Code, jedes „Das räume ich später auf", das nie passiert. Wie finanzielle Schulden sammeln sie Zinsen an: unordentlicher Code braucht länger zum Ändern, versteckt Bugs und verlangsamt neue Teammitglieder. Kontinuierliches Refactoring ist die Art, wie Teams Schulden abbauen, bevor sie sich zu einer nicht mehr handhabbaren Codebasis aufschaukeln.
Schätzung & Planung
4 BegriffeStory Points
Story Points sind eine Einheit relativer Schätzung, die Aufwand, Komplexität und Unsicherheit kombiniert statt Zeit. Eine 5-Punkte-Story ist ungefähr doppelt so aufwändig wie eine 2-Punkte-Story, aber nicht unbedingt doppelt so viele Stunden. Gängige Skalen sind Fibonacci (1, 2, 3, 5, 8, 13), Zweierpotenzen und T-Shirt-Größen, wobei die Lücken zwischen den Werten eine echte Entscheidung erzwingen.
Velocity
Velocity ist die Anzahl der Story Points, die ein Team pro Sprint abschließt, und wird verwendet, um relative Schätzungen in Prognosen umzuwandeln. Die Logik ist „das Wetter von gestern": Ein Team, das durchschnittlich 25 Punkte geschafft hat, wird wahrscheinlich im nächsten Sprint etwa 25 schaffen. Velocity ist ein Planungswerkzeug, keine Produktivitätsmetrik – setzt du Ziele darauf, inflationieren Teams einfach ihre Schätzungen.
Planning Poker
Planning Poker ist eine Schätztechnik, bei der alle ein Arbeitspaket privat schätzen und im selben Moment aufdecken, was das Ankern an der ersten genannten Zahl eliminiert. Die Streuung ist das Signal: Eine einstimmige 3 bedeutet gemeinsames Verständnis und ihr macht weiter, während eine Spaltung zwischen 2 und 13 bedeutet, dass zwei Personen sich grundlegend unterschiedliche Arbeit vorstellen.
Mehr: Die minimal nützliche Schätzung (Grundlagen der Software-Auslieferung)
Sprint
Ein Sprint ist eine Iteration mit fester Länge von einem Monat oder weniger, die als Herzschlag von Scrum dient und alle anderen Scrum-Events enthält. Sprints laufen direkt hintereinander ohne Lücken, jeder trägt ein Sprint-Ziel, das Fokus gibt, und jeder sollte mit einem potenziell auslieferbaren Inkrement enden. Konsistente Sprint-Länge schafft Rhythmus und Vorhersagbarkeit.
Zeremonien
5 BegriffeRetrospektive
Eine Retrospektive ist ein regelmäßiges Team-Meeting, das untersucht, wie das Team im letzten Sprint zusammengearbeitet hat, und einen Verbesserungsplan erstellt. Teilnehmer sind nur das Team, ohne Stakeholder, und das Ergebnis ist eine kleine Anzahl umsetzbarer Verbesserungen. Sie ist das Herzstück kontinuierlicher Verbesserung: Lässt du sie ausfallen, hört das Team auf, besser zu werden.
Standup (Daily Scrum)
Ein Standup, im Scrum als Daily Scrum bezeichnet, ist ein tägliches 15-Minuten-Event, bei dem Entwickler den Fortschritt zum Sprint-Ziel prüfen und den Plan für den Tag anpassen. Es ist Koordination, keine Statusberichterstattung: Das Ergebnis ist ein aktualisierter Plan, und Blocker tauchen hier auf, werden aber danach gelöst, nicht während des Meetings.
Asynchrones Standup
Ein asynchrones Standup ist ein Standup, das ohne synchrones Meeting stattfindet: Updates werden automatisch aus bereits in Tools wie Jira, Linear, GitHub und GitLab erfassten Aktivitäten generiert oder schriftlich nach eigenem Zeitplan eingereicht. Die Prämisse ist einfach: Wenn die Arbeit bereits irgendwo erfasst ist, sollten Menschen sie nicht wiederholen müssen.
Action Item
Ein Action Item ist eine spezifische, zugewiesene Verpflichtung, etwas zu ändern, typischerweise aus einer Retrospektive. Die meisten sterben leise: Eine PMI-Community-Umfrage ergab, dass fast zwei Drittel der Teams weniger als 25 % ihrer Retrospektive-Action-Items umsetzen. Jedes aufgegebene Item ist ein kleines gebrochenes Versprechen, und genug gebrochene Versprechen lehren ein Team, keine Probleme mehr anzusprechen.
Psychologische Sicherheit
Psychologische Sicherheit ist die Überzeugung, dass du dich mit Fragen, Bedenken, Fehlern oder abweichenden Meinungen äußern kannst, ohne Bestrafung oder Demütigung. Es geht nicht darum, nett zu sein; es geht darum, Offenheit zu ermöglichen. Googles Project Aristotle fand heraus, dass psychologische Sicherheit der wichtigste Prädiktor für leistungsstarke Teams war, wichtiger als individuelles Talent.
Mehr: Psychologische Sicherheit schaffen (Scrum Master Essentials)
Messung & Metriken
10 BegriffeDORA-Metriken
DORA-Metriken sind vier Maße für die Software-Delivery-Performance: Deployment-Frequenz, Lead Time für Änderungen, Change Failure Rate und Mean Time to Restore. Sie stammen aus dem DevOps Research and Assessment-Programm hinter der Accelerate-Forschung und den jährlichen State of DevOps-Reports, die durchweg zeigen, dass Elite-Performer schneller mit weniger Fehlern ausliefern. Isoliert gemessen sind sie Instrumentierung statt Einsicht.
Deployment-Frequenz
Deployment-Frequenz ist die DORA-Metrik, die misst, wie oft ein Team Code in die Produktion ausliefert. Sie kann automatisch aus CI/CD-Pipelines wie GitHub Actions, GitLab CI/CD und Bitbucket Pipelines berechnet werden. Über die reine Zahl hinaus ist sie ein Beleg für echten Durchsatz: Ein Team, das häufig mit stabiler Qualität deployed, demonstriert Lieferung, nicht nur das Schließen von Tickets.
Lead Time für Änderungen
Lead Time für Änderungen ist die DORA-Metrik, die misst, wie lange Code vom Commit bis zum Produktivbetrieb braucht. Lange Lead Times gehen meist auf hohe WIP-Werte, große Batch-Größen oder Review-Engpässe zurück statt auf langsames Programmieren – deshalb liest du diese Metrik am besten zusammen mit den Flow-Signalen, die bereits in deinen Projektmanagement-Daten stecken.
Change Failure Rate
Change Failure Rate ist die DORA-Metrik, die den Prozentsatz der Produktiv-Deployments misst, die einen Fehler verursachen, der behoben werden muss. Sie ist ein Qualitätssignal: Spitzen korrelieren oft mit engen Zeitplänen, neuen Mitwirkenden oder Infrastruktur-Änderungen – deshalb ist die Zahl am nützlichsten, wenn sie mit dem Sprint-Kontext verbunden ist, der sie erklärt.
Mean Time to Restore (MTTR)
Mean Time to Restore, oder MTTR, ist die DORA-Metrik, die misst, wie lange es dauert, den Service nach einem Produktivausfall wiederherzustellen. Schnelle Wiederherstellung signalisiert starke Incident Response und tiefe Vertrautheit mit der Codebasis – deshalb liest sich MTTR als Ownership- und Operations-Signal statt als reine Geschwindigkeitszahl.
Developer Effectiveness
Developer Effectiveness ist ein Maß dafür, ob die Arbeit eines Engineers dauerhafte Ergebnisse schafft, nicht wie viel Aktivität sie erzeugt. Simyl Flow bewertet sie über sechs Dimensionen: Delivery, Flow, Quality, Collaboration, Ownership und Adaptability. Mehrdimensionale Bewertung verhindert Gaming, und die Messung bleibt ergebnisorientiert: kein Keystroke-Tracking, keine Tool-Nutzungs-Überwachung, und individuelle Profile sind standardmäßig privat.
Developer Productivity vs. Developer Effectiveness
Developer Productivity und Developer Effectiveness sind unterschiedliche Maße: Productivity zählt Aktivität (Commits, Codezeilen, geschlossene Tickets), während Effectiveness Ergebnisse misst – ob gelieferte Arbeit dauerhaften Wert geschaffen hat. Der Unterschied ist wichtig, weil Aktivitätsmetriken zu Überwachung und Gaming einladen, während Effectiveness aus Ergebnissen schließt statt Tool-Nutzung zu tracken und Coaching statt Bewertung bevorzugt.
Health Score
Ein Health Score ist eine Bewertung von 0 bis 100 mit Noten von A bis F, die die Sprint-Gesundheit eines Teams über die sechs Effectiveness-Dimensionen zusammenfasst. Seine Aufgabe ist es, die Verbesserungsschleife zu schließen: Nachdem eine Retrospektive die Arbeitsweise des Teams verändert hat, zeigt der Health-Score-Trend, ob diese Änderung tatsächlich etwas bewegt hat.
Goodharts Gesetz
Goodharts Gesetz ist die Beobachtung, benannt nach dem britischen Ökonomen Charles Goodhart, dass „wenn ein Maß zum Ziel wird, es aufhört, ein gutes Maß zu sein". Im Engineering zeigt es sich als Metrik-Gaming: Velocity wird zum Ziel und Schätzungen blähen sich auf; Stories Closed wird zum Ziel und Arbeit wird als erledigt markiert, bevor sie fertig ist. Das Dashboard bleibt grün, während die Delivery leidet.
Vanity-Metriken
Vanity-Metriken sind Zahlen, die steigen, ohne mit Geschäftsergebnissen zu korrelieren: Commits pro Tag, Codezeilen, abgeschlossene Story Points, gemergte PRs. Sie sind verlockend, weil sie einfach zu erfassen sind und zufriedenstellende Grafiken ergeben, aber sie schaffen falsche Anreize und eine Illusion von Transparenz. Der Test: Wenn sich diese Zahl verdoppelt, verdoppelt sich dann der Geschäftswert?
Methoden
5 BegriffeScrum
Scrum ist ein schlankes agiles Framework zur Entwicklung komplexer Produkte, das auf Empirie basiert: Transparenz, Inspektion und Anpassung. Es definiert drei Rollen (Product Owner, Scrum Master, Entwickler), fünf Events einschließlich des Sprints und der Retrospektive sowie drei Artefakte. Der Scrum Guide umfasst nur 13 Seiten, weil Scrum absichtlich unvollständig ist: ein Framework mit Leitplanken, keine Schritt-für-Schritt-Methodik.
Kanban
Kanban ist eine adaptive Methode zur Verwaltung von Wissensarbeit, die den Workflow visualisiert, laufende Arbeit begrenzt und den Prozess schrittweise weiterentwickelt. Seine Philosophie lautet „fang an, wo du bist": keine vorgeschriebenen Rollen, keine erforderlichen Events, keine festen Iterationen. Es entstand aus dem Toyota-Produktionssystem und wurde in den 2000er Jahren von David J. Anderson für Software adaptiert.
Extreme Programming (XP)
Extreme Programming (XP) ist eine agile Methodik, die durch Kent Becks Buch Extreme Programming Explained von 1999 etabliert wurde und präskriptiv in Bezug auf Engineering-Praktiken ist, wo Scrum schweigt: Schreib zuerst Tests, programmiere im Pair, refaktoriere kontinuierlich und integriere mehrmals täglich. Seine fünf Werte sind Kommunikation, Einfachheit, Feedback, Mut und Respekt.
Pair Programming
Pair Programming bedeutet, dass zwei Entwickler zusammen an einer Workstation arbeiten: Einer tippt (der Driver), während der andere beobachtet, vorausdenkt und navigiert. In der XP-Literatur zitierte Forschung zeigt, dass Pairs Code mit etwa 15 % weniger Fehlern produzieren und dabei nur etwa 15 % mehr Zeit benötigen – effektiv kontinuierliches Code-Review plus Wissensverbreitung im Team.
Test-Driven Development (TDD)
Test-Driven Development (TDD) ist die Praxis, einen fehlschlagenden Test zu schreiben, bevor man Produktionscode schreibt, wiederholt in einem Red-Green-Refactor-Zyklus: Schreib einen fehlschlagenden Test, schreib den minimalen Code, um ihn zu bestehen, dann räum auf, während die Tests grün bleiben. TDD ist eine Designtechnik, die als Testtechnik getarnt ist; das Denken, das die Tests hervorbringt, ist der Punkt.
KI & Werkzeuge
3 BegriffeMCP (Model Context Protocol)
MCP, das Model Context Protocol, ist ein offenes Protokoll, das KI-Assistenten wie Claude und ChatGPT ermöglicht, sich direkt mit externen Tools und Datenquellen zu verbinden. Simyl Flow stellt 17 schreibgeschützte MCP-Tools über 8 Bereiche bereit, die Standups, Retros, Metriken und Action Items abdecken, damit die KI-Assistenten, die ein Team einsetzt, abfragen können, ob sie tatsächlich helfen.
Workflow-Abgase
Workflow-Abgase sind die strukturierten Daten, die deine vorhandenen Tools bereits als Nebenprodukt der normalen Arbeit ausgeben: Commit-Historie, PR-Reviews, Ticket-Übergänge und CI/CD-Pipeline-Läufe. Das Prinzip hinter dem Begriff: Die Daten, die zur Messung der Lieferung benötigt werden, existieren bereits; das Problem war nie die Verfügbarkeit, sondern dass sie in Silos lagen, getrennt vom Kontext, der sie aussagekräftig macht.
Ausliefern und halten
Ausliefern und halten ist ein Messrahmen, der zwei Fragen zu jeder Änderung in der Arbeitsweise eines Teams stellt, sei es ein neues Tool, ein Prozess oder ein KI-Assistent: Wurde die Arbeit ausgeliefert, und hat sie weiterhin Wert in der Produktion geschaffen? Zu seinen Vitalzeichen gehören die Nacharbeitsrate (Reverts und Hotfixes), die Qualitätsentwicklung im Zeitverlauf und die Vorhersagbarkeit der Lieferung, die zusammen und nicht isoliert betrachtet werden.
Definitionen sind der einfache Teil
Zu wissen, was Zykluszeit bedeutet, ist nicht dasselbe wie deine zu kennen. Simyl Flow berechnet diese Metriken aus den Tools, die dein Team bereits nutzt, und zeigt, ob deine Änderungen funktionieren.