WIP-Monitoring für Azure DevOps-Teams, die Engpässe früher stoppen wollen
Wer nach Azure DevOps WIP-Monitoring sucht, will meist eine gesündere Kultur des „nicht mehr anfangen, sondern fertigstellen“ etablieren. Agile Analytics macht WIP-Druck und alternde Arbeit direkt im bestehenden Workflow des Teams sichtbar: Die WIP-Monitor-Ansicht prüft jedes konfigurierte Team gegen sein eigenes Limit, und das Aging Chart zeigt, wie lange jedes laufende Element schon ohne Abschluss liegt.
Warum WIP-Probleme zu spät auffallen
- Arbeit stapelt sich in Bearbeitung, ohne ein klares Signal, wann das System überlastet ist
- Alternde Arbeit und blockierte Elemente werden zu spät sichtbar
- Teams wollen durchgehendes Monitoring, ohne eine weitere Plattform zu betreiben
Was Ihnen Azure DevOps WIP-Monitoring bringt
- Sehen Sie die laufende Arbeit jedes konfigurierten Teams im Verhältnis zu seinem eigenen WIP-Limit, mit einer zusammenfassenden Aussage und einem nach Risiko sortierten Auslastungsdiagramm
- Heben Sie blockierte oder langsame Elemente hervor, bevor sie das Sprintergebnis gefährden, mit Alterungsschwellen, die auf Ihre eigene Cycle-Time-Historie abgestimmt sind
- Senden Sie eine Teams- oder Slack-Benachrichtigung an Ihren eigenen Kanal, wenn ein Team sein Limit überschreitet, direkt aus Ihrem Tenant, ohne Relay über den Publisher
Was der WIP Monitor in Agile Analytics tatsächlich zählt
Der WIP Monitor ist die Azure DevOps-Ansicht für eine Frage: Welche Teams tragen mehr laufende Arbeit, als sie sich vorgenommen haben. Sie konfigurieren die zu beobachtenden Teams und ein WIP-Limit für jedes im WIP-Regeln-Panel unter Konfiguration. Für jedes konfigurierte Team liest die Ansicht den aktiven Sprint und zählt die Work Items, die begonnen, aber noch nicht abgeschlossen sind, anhand Ihres gespeicherten Workflow-Mappings, sodass ein benutzerdefinierter Status wie „Code Review“ weiterhin als laufend zählt. Aktuelles WIP geteilt durch das Limit ergibt eine Auslastung in Prozent, und jedes Team landet in einem von drei Zuständen: gesund, nahe am Limit oder über dem Limit. Wie früh ein Team als „nahe am Limit“ gilt, bestimmt ein Schwellenwertmodus, den Sie wählen: Konservativ warnt mit dem meisten Spielraum, Aggressiv warnt am spätesten, und Standard liegt dazwischen. Ein Team ohne aktiven Sprint, ohne Daten oder mit einem fehlgeschlagenen Lesevorgang wird genau so angezeigt. Agile Analytics stuft ein Team, das nicht geprüft werden konnte, niemals stillschweigend als gesund ein.
Die zusammenfassende Aussage und das Team-Auslastungsdiagramm
Oben im WIP Monitor steht ein einzelner Satz: "2 of 7 teams over their WIP limit", "1 of 7 teams near their WIP limit" oder "All 7 teams within their WIP limits". Konnten einige Teams nicht gelesen werden, nennt der Satz, wie viele geprüft wurden und wie viele nicht, statt den Eindruck zu erwecken, die nicht lesbaren seien in Ordnung. Darunter zählt eine Statuszeile Teams, über Limit, nahe Limit und gesund, und ein Auslastungsdiagramm zeichnet jedes Team als Balken auf einer gemeinsamen Prozentachse mit Referenzlinien bei 85 und 100 Prozent, sodass ein Team über dem Limit auch von Weitem sofort auffällt. Das Diagramm sortiert nach Risiko (zuerst Überschreitungen, dann Warnungen, innerhalb jeder Gruppe die stärksten zuerst), nach Auslastung oder alphabetisch, und lässt sich auf die obersten N Teams begrenzen, während die Aussage und die Zählung weiterhin jedes Team erfassen. Wechseln Sie bei den Balken zwischen Anzahl der Elemente und Story Points; sind Story Points aktiv, zeigt die Ansicht, wie viele laufende Elemente keine Schätzung tragen, statt sie stillschweigend als null zu zählen. Die Fußzeile stempelt den Snapshot-Zeitpunkt ehrlich: Zählungen können aus einem kurzen Session-Cache stammen, daher steht dort "Snapshot" statt vorzugeben, jeder Aufruf sei ein frischer Lesevorgang.
WIP-Verlauf: Ob sich ein Team in Richtung Überlastung bewegt
Der Verlauf-Tab macht aus derselben Zählung einen Trend. Wählen Sie ein Team und eine Anzahl vergangener Sprints (standardmäßig acht), und die Ansicht stellt die laufende Arbeit dar, gemessen jeweils zur Sprintmitte, ergänzt durch eine Tabelle pro Sprint. Ein Team, dessen WIP von Sprint zu Sprint steigt, während der Durchsatz gleich bleibt, baut einen Rückstand auf, und dieses Muster ist hier Wochen sichtbar, bevor es sich als längere Cycle Time zeigt. Das ist dieselbe Historie, die die Flow-Metriken-Ansicht für ihre Prüfung nach dem Little’s Law verwendet, sodass sich beide Ansichten nie über den WIP-Wert widersprechen können. Beide Tabs lassen sich für Retrospektiven und Management-Reporting als CSV exportieren.
Alternde Work Items und blockierte Arbeit an einem Ort
Ein Team kann innerhalb seines WIP-Limits liegen und trotzdem drei Elemente haben, die sich seit zwei Wochen nicht bewegt haben; deshalb kombiniert WIP-Monitoring in Agile Analytics den WIP Monitor mit dem Aging Chart (der Ansicht Aging & Blocked). Es ordnet laufende Arbeit Lane für Lane an und zeigt, wie viele Tage jedes Element bereits in seinem aktuellen Status verbracht hat, mit Verlaufs-Chips, die zeigen, wo das Element schon war, gruppiert in Altersgruppen, sodass die ältesten Elemente sofort ins Auge fallen. Blockierte Arbeit wird über die Signale erkannt, die Teams in Azure DevOps tatsächlich nutzen: ein Blocked-Tag, das Feld Blocked, ein blockierter Status oder eine Board-Spalte, oder ein Hinweis im Titel, und diese Elemente werden separat mit dem Grund aufgeführt. Das Trenddiagramm zeichnet drei Zonen (gesund, beobachten, überaltert) aus dem 50. und 85. Perzentil der Cycle Time Ihres eigenen Teams statt aus einer Branchen-Faustregel, sodass „alt“ für dieses Team auch wirklich alt bedeutet. Abgeschlossene Sprints werden zum Stand ihres Enddatums nachgebildet, sodass eine Retrospektive zeigt, wie der Sprint tatsächlich aussah, statt das heutige Board, und Elemente in Status, die Ihr Mapping nicht abdeckt, werden gezählt und offen ausgewiesen statt verworfen.
Benachrichtigungen an Teams oder Slack, wenn ein Team sein Limit überschreitet
Jedes beobachtete Team kann auf einen eingehenden Microsoft Teams- oder Slack-Webhook verweisen. Stellt Agile Analytics bei der WIP-Prüfung fest, dass ein Team über seinem Limit liegt (oder nahe daran, wenn Sie diese Benachrichtigung aktiviert lassen), postet es eine kurze Nachricht wie "Platform team: WIP 9/8 (limit exceeded)" in diesen Kanal, mit einem Link zurück zur Ansicht. Benachrichtigungen werden pro Browser-Sitzung dedupliziert, damit ein Kanal nicht mit derselben Überschreitung überflutet wird. Eine ehrliche Einschränkung, die Sie kennen sollten, bevor Sie darauf planen: Die Prüfung läuft, wenn jemand Agile Analytics innerhalb von Azure DevOps geöffnet hat, weil kein beim Publisher gehostetes Backend Ihre Work Items nach einem Zeitplan liest. Das ist dieselbe Designentscheidung, die Ihre Work-Item-Daten innerhalb Ihres Azure DevOps-Tenants hält und bedeutet, dass die Erweiterung kein Personal Access Token braucht. Der Webhook-Aufruf geht von Ihrem Browser direkt an Ihren eigenen Teams- oder Slack-Endpunkt, und ausschließlich an die Webhook-Hosts von Microsoft und Slack, niemals über ein von uns betriebenes Relay.
WIP- und Flow-Funktionen ansehen
Der WIP Monitor, die Ansicht Aging & Blocked und der Rest der Flow-Analysen: Cycle-Time-Streudiagramm, Cumulative Flow, Trends der Flow-Effizienz.
Seite öffnen →Den WIP Guide lesen
Warum WIP-Disziplin der günstigste Hebel für kürzere Cycle Times ist und wie Sie realistische Limits setzen, ohne das Team auszubremsen.
Seite öffnen →Cycle-Time-Analysen ansehen
Die andere Hälfte des Flow-Bilds: perzentilbasierte Cycle Time, Service-Erwartungen und wie sich WIP-Disziplin in den Zahlen zeigt.
Seite öffnen →Fragen zum WIP-Monitoring
Hilft WIP-Monitoring nur Kanban-Teams?
Nein. Auch Scrum-Teams profitieren, weil überlastete laufende Arbeit oft die Erklärung für späte Burndown-Bewegungen und unregelmäßige Sprint-Abschlussmuster ist.
Wird das WIP-Limit pro Board-Spalte oder pro Team gesetzt?
Pro Team. Im WIP-Regeln-Panel fügen Sie jedes zu beobachtende Team hinzu und geben ihm ein Limit für die gesamte laufende Arbeit sowie einen Schwellenwertmodus, der bestimmt, wie früh es als nahe am Limit markiert wird. Das Aging Chart ist die Ansicht, die die Arbeit Lane für Lane aufschlüsselt.
Laufen die WIP-Benachrichtigungen, wenn niemand das Dashboard geöffnet hat?
Nein, und das sagen wir lieber offen, als etwas anderes anzudeuten. WIP wird geprüft, wenn jemand Agile Analytics in Azure DevOps geöffnet hat, und jede Teams- oder Slack-Benachrichtigung wird aus dieser Sitzung an Ihren eigenen Webhook gesendet. Es gibt keinen beim Publisher gehosteten Dienst, der Ihre Work Items abfragt, weshalb Ihre Daten auch nie Ihren Tenant verlassen und kein Personal Access Token nötig ist.
Was ist der praktische Nutzen für Führungskräfte?
Es macht unsichtbares Flow-Risiko zu etwas, über das das Team täglich sprechen kann, statt es erst am Ende des Sprints zu entdecken.