Das Projekt geht los, die Aufgaben sind verteilt und dein Team ist motiviert. Besser geht es nicht. Wer jetzt jedoch nicht aufpasst und zu viele Aufgaben parallel bearbeitet, wird zum Ende des Sprints Probleme bekommen. Aus Erfahrung wissen wir, dass jeder Mitarbeiter mit mehr als 2 Aufgaben gleichzeitig bereits ausreichend ausgelastet ist. Mehr Tickets schaffen nur ein Fokusproblem. Genau dafür gibt es WIP-Limits.
Was ein WIP-Limit macht
WIP steht für Work in Progress, also angefangene Arbeit. Ein WIP-Limit legt fest, wie viele Tickets in einer Status-Spalte gleichzeitig liegen sollen. Steht in “In Bearbeitung” ein Limit von 5 und liegen dort 8 Tickets, ist das ein sichtbares Signal: Bevor jemand etwas Neues anfängt, sollte er zuerst Angefangenes abschließen.
Warum paralleles Arbeiten langsamer ist
Fünf Tickets gleichzeitig fühlen sich nach mehr Leistung an als eins nach dem anderen. Im Projektalltag ist es umgekehrt.
Jeder Wechsel kostet Zeit: Du liest dich neu ein, rekonstruierst den Stand, erinnerst dich, warum du etwas so gelöst hast. Bei fünf offenen Tickets machst du das den ganzen Tag.
Dazu kommt der Blick des Kunden. Ein Ticket, das zu 90 Prozent fertig ist, bringt ihm genauso viel wie eines, das noch niemand angefangen hat, nämlich nichts. Er bezahlt den Abschluss und nicht den Fortschritt.
Wo das Limit im Taskboard sitzt
Im Taskboard des Reporting Plugins setzt du das Limit pro Status-Spalte. Der Spaltenkopf zeigt dann die Auslastung als “Anzahl / Limit”, also zum Beispiel 5 / 3. Ist das Limit überschritten, erscheint die Zahl rot und fett, beim Drüberfahren mit der Maus siehst du einen Hinweistext.
Es gibt zwei Wege, ein Limit zu setzen. Beide funktionieren nur bei gespeicherten Abfragen und nur, wenn du die Abfrage bearbeiten darfst:
- Im Abfrage-Formular: Beim Bearbeiten der Abfrage findest du im Abschnitt Optionen ein Feld pro Status-Spalte. Trage dort die gewünschte Zahl ein, leer bedeutet kein Limit.
- Direkt am Board: Fahre über einen Spaltenkopf und klicke auf das Limit. Zahl eingeben, Enter drücken, fertig. Escape bricht ab.
Weil das Limit zur gespeicherten Abfrage gehört, kann jedes Board eigene Limits haben. Das Board deines Support-Teams arbeitet also mit anderen Grenzen als das der Entwicklung, ohne dass sich beide in die Quere kommen.
Drei Dinge solltest du dabei wissen:
- Das Limit blockiert nichts. Du kannst ein Ticket weiterhin in eine volle Spalte ziehen, das Board markiert die Spalte dann nur. Das ist Absicht, denn ein Limit soll ein Gespräch auslösen und nicht die Arbeit verhindern.
- Das Limit gilt für die gesamte Spalte, also über alle Swimlanes hinweg. Swimlanes sind die waagrechten Zeilen, in die ein gruppiertes Board aufgeteilt ist.
- Limit 0 bedeutet “diese Spalte sollte leer bleiben”. Sobald ein Ticket darin liegt, ist die Spalte markiert. Praktisch für Spalten, in denen nichts liegenbleiben darf.
Welche Zahl ist optimal?
Das ist die Frage, die immer zuerst kommt. Ein guter Startwert:
Anzahl der Personen in dieser Spalte plus eins.
Bei vier Entwicklern also fünf. Das entspricht ungefähr den zwei Aufgaben pro Person, mit denen die meisten gut zurechtkommen, und lässt Luft für den Fall, dass jemand hängenbleibt und etwas anderes anfangen muss.
Entscheidend ist aber nicht der Startwert, sondern was danach passiert. Schau dir das Board ein paar Wochen an: Reißt ihr das Limit ständig und niemanden stört es, ist es zu niedrig oder das Team nimmt es nicht ernst. Erreicht ihr es nie, kannst du es dir sparen.
Für welche Spalten sich ein Limit lohnt:
- In Bearbeitung: hier gehört fast immer eins hin, das ist der klassische Fall
- Review: oft die eigentliche Engstelle, weil Prüfen ungeliebt ist und liegenbleibt
- Backlog: hier ergibt ein Limit meist keinen Sinn, da sammelt ihr bewusst
- Wartet auf Kunde: ein Sonderfall, denn das Limit zeigt dir, wie viel Arbeit gerade außerhalb deiner Kontrolle hängt
Wenn das Limit greift
Sobald die Spalte rot wird, steht eine Entscheidung an.
Die richtige Reaktion ist selten “Limit erhöhen”. Meistens lautet die Frage: Warum kommen die Tickets in dieser Spalte nicht weiter? Aus der Praxis kennen wir vor allem drei Gründe:
- Ein Ticket wartet seit Tagen auf eine Rückmeldung, die niemand einfordert
- Zwei Tickets sind eigentlich blockiert, aber niemand hat es sichtbar gemacht
- Die Spalte davor schiebt schneller nach, als diese Spalte abarbeiten kann
In allen drei Fällen hilft ein höheres Limit nicht. Es würde das Problem nur wieder unsichtbar machen.
Dabei ergänzen sich zwei Funktionen des Boards. Das rote Schloss auf einer Karte zeigt, dass ein anderes, noch offenes Ticket dieses Ticket blockiert. Zusammen mit einem überschrittenen Limit siehst du also nicht nur, dass etwas hängt, sondern auch woran.
Das Limit setzt ihr im Team fest
WIP-Limits wirken nur, wenn das Team dahinter steht. Eine Zahl, die die Projektleitung allein festlegt und die alle ignorieren, bleibt eine rote Ziffer im Spaltenkopf.
Setz das erste Limit deshalb gemeinsam fest und nicht allein am Schreibtisch. Klärt vorher, was bei einer Überschreitung passiert, und sei es nur, dass ihr die Spalte im nächsten Daily kurz durchgeht.
So fängst du an
- Öffne deine Ticketliste und wechsle unter Optionen bei Ergebnisse anzeigen als auf Board
- Speichere die Ansicht als benutzerdefinierte Abfrage, am besten geteilt mit deinem Team
- Setz ein Limit auf der Spalte “In Bearbeitung”: Anzahl der Personen plus eins
- Beobachte zwei bis drei Wochen und sprich das Limit im Team an, wenn es rot wird
- Passe die Zahl an, wenn ihr genug Erfahrung gesammelt habt
Mehr braucht es nicht für den Anfang. Alle weiteren Spalten kannst du später ergänzen.
Alle Informationen zu unseren Erweiterungen für Redmine gibt es auf der Produktseite. Das kostenpflichtige Reporting Plugin gibt es einzeln oder als Teil unseres Business-Class Bundle, sowie dem Enterprise+ Bundle. Die hier beschriebene Funktion kann in unserer Online-Demo ausgiebig getestet werden.