Ein Work-in-Progress-Limit ist eine der günstigsten Prozessänderungen, die ein Team vornehmen kann: eine Zahl wählen, sie aufs Board schreiben, sich einig sein, keine neue Arbeit darüber hinaus zu beginnen. Azure Boards lässt Sie ohne Weiteres eine Spalte mit einem Limit beschriften. Was es nicht von allein tut, ist Ihnen Sprint für Sprint zu sagen, ob das Team tatsächlich innerhalb dieser Zahl liegt oder seit drei Wochen still darüber ist, während alle auf die Board-Spalten geschaut haben, statt zu zählen.
Was „in Bearbeitung" tatsächlich bedeutet
Ein WIP-Limit ist nur ehrlich, wenn „in Bearbeitung" etwas Konkretes bedeutet. Ein Item zählt als in Bearbeitung, wenn es bis zu oder vor dem gemessenen Zeitpunkt ein echtes Signal für den Arbeitsbeginn hat, einen zugeordneten Übergang in „in Bearbeitung" oder ein Activated Date, und zu diesem Zeitpunkt noch nicht abgeschlossen ist. Nur angelegt und im Sprint geparkt zu sein, zählt nicht als begonnen; ein Backlog unangefasster Items in einem Sprint sollte eine WIP-Zahl, die aktive Arbeit messen soll, nicht stillschweigend aufblähen.
WIP-Monitor: eine Zahl, ein Badge
Die WIP-Monitor-Ansicht von Agile Gauge ist auf das jeweils in der oberen Leiste des Hubs ausgewählte Team beschränkt und zeigt eine einzelne Zahl „jetzt in Bearbeitung" für den laufenden Sprint, dazu ein Badge: Über dem Limit, Nahe dem Limit oder Kein Limit gesetzt, das nur angezeigt wird, wenn es Aufmerksamkeit braucht. Wenn alles in Ordnung ist, wird nichts Zusätzliches angezeigt, und das ist Absicht: Ein Bildschirm, den jemand täglich prüft, sollte nicht sorgfältig gelesen werden müssen, um zu wissen, ob etwas nicht stimmt.
Wo das Limit tatsächlich liegt
Das Limit selbst wird in der Konfiguration festgelegt und für Sie, für dieses Team, gespeichert: gut zu wissen, bevor eine Uneinigkeit ausbricht, denn es ist eine persönliche Einstellung, keine für das ganze Team gemeinsame. Zwei Personen im selben Team können jeweils eine andere Zahl festlegen, und jede sieht sie als gespeichert an; die Konfiguration weist direkt neben der Eingabe klar darauf hin. Wenn ein Teammitglied für dasselbe Team ein anderes Limit meldet als Sie, ist das kein Fehler: es bedeutet nur, dass sich das Team noch nicht tatsächlich auf eine Zahl geeinigt hat, sondern dass jeder von Ihnen unabhängig etwas eingegeben hat.
Der Status wird in drei Stufen bewertet: über dem Limit ist „über dem Limit"; bei 80 % des Limits oder mehr, aber nicht darüber, ist „nahe dem Limit": genau am Limit selbst zählt noch als „nahe", nicht als „über", da nur ein echtes Überschreiten die stärkere Warnung auslösen sollte. Kein Limit gesetzt ist ein eigener, klar abgegrenzter Status, der nie stillschweigend als „gesund" behandelt wird, nur weil es nichts zum Vergleichen gibt.
Was tatsächlich in die Zahl einfließt
Nur die Work-Item-Typen, die Ihre Organisation so konfiguriert hat, dass sie in die Metriken einfließen, zählen zum WIP: standardmäßig geplante Arbeit wie Storys und Product Backlog Items, Bugs und Research-Items. Tasks und andere Typen sind standardmäßig ausgeschlossen, sofern ein Team sie nicht bewusst in der Konfiguration hinzufügt, da das Mitzählen jedes Subtasks neben jeder Story dazu neigt, den WIP weit schlimmer aussehen zu lassen, als der tatsächliche Engpass ist, den ein Team erkennen möchte.
Eine Zahl wählen, die es wert ist, eingehalten zu werden
Der schwierigste Teil eines WIP-Limits ist selten das Werkzeug: es ist die Einigung auf die Zahl selbst. Ein zu hoch angesetztes Limit schränkt eigentlich nie etwas ein, und das Team erfährt nie, was es eigentlich verhindern sollte. Ein zu niedrig angesetztes Limit wird innerhalb einer Woche zu einer Regel, die niemand befolgt, was schlimmer ist als gar kein Limit, weil es dem Team beibringt, dass Limits nur Dekoration sind. Ein vernünftiger Einstieg ist, nahe an dem zu beginnen, was die tatsächliche Anzahl in Bearbeitung befindlicher Items des Teams zuletzt tatsächlich war: das eigene Trend-Diagramm des WIP-Monitors zeigt genau das, und es allmählich zu verschärfen, sobald sich das Team wohlfühlt, darunter zu bleiben, statt eine Zahl aus einer Schulungsfolie zu nehmen und zu hoffen, dass sie passt.
Es lohnt sich auch, sich laut darauf zu einigen, was passiert, wenn das Team das Limit erreicht: Beendet jemand etwas, bevor das nächste Item begonnen wird, oder wird das Limit still „nur dieses eine Mal" ignoriert? Ein Limit, das uneinheitlich durchgesetzt wird, bringt dem Team bei, dass es optional ist, was den ganzen Sinn eines Limits zunichtemacht: die Zahl in der Konfiguration erfüllt ihren Zweck nur, wenn das Team tatsächlich zugestimmt hat, sie zu respektieren.
Den Trend lesen, nicht nur den heutigen Tag
Die Zahl eines einzelnen Tages beantwortet „sind wir gerade darüber", aber nicht „wird das schlimmer". Unter dem Limit und dem Badge zeigt ein Balkendiagramm den mittleren WIP-Stand für die letzten bis zu acht Sprints, mit dem WIP-Limit als Referenzlinie, sofern eines gesetzt ist. Ein Team, das gelegentlich etwas über seinem Limit liegt, sieht ganz anders aus als eines, das seit zwei Monaten stetig ansteigt: dieselbe Tageszahl könnte zu beiden Teams gehören, aber das Diagramm unterscheidet sie.
Bekannte Grenzen
Der WIP-Monitor ist jeweils auf ein Team beschränkt: es gibt auf dieser Ansicht keine Tabelle über alle Teams und keinen CSV-Export. Die Historie ist auf die letzten acht Sprints begrenzt, und der Nahe-Limit-Schwellenwert ist fest auf 80 % gesetzt, nicht pro Team über diesen Bildschirm konfigurierbar. Keine der Kacheln hier führt zu einer Work-Item-Liste, abgesehen von der Schaltfläche des Banners „kein Limit gesetzt", die direkt zur Konfiguration führt: der WIP-Monitor ist dafür gebaut, schnell eine Frage zu beantworten, nicht ein allgemeiner Item-Browser zu sein.
Der Weg dorthin
Zwei Dinge müssen einmalig eingerichtet werden: welche Work-Item-Typen in die Metriken einfließen, und das Limit selbst, beides in der Konfiguration. Danach liest der WIP-Monitor jedes Mal, wenn Sie ihn öffnen, den aktuellen Sprint Ihres Teams: nichts, was von Hand neu berechnet werden muss, und nichts, das zwischen den Stand-ups veraltet.
Agile Gauge startet bei 20 $ im Monat für bis zu 2 Benutzer. Starten Sie eine kostenlose 14-tägige Testversion: mit vollem Funktionsumfang, keine Kreditkarte erforderlich.