Ich bin ja bekanntlich ein Fan davon, in einem Team ein gemeinsames Modell des Arbeitssystems zu erstellen und die Arbeit anschliessend über dieses Modell sichtbar und besprechbar zu machen. Dies wiederum generiert eine gemeinsame Vorstellung davon, wie das Arbeitssystem optimiert werden kann.
Wenn man dieses Modell neu aufbaut, ist es hilfreich, auf bewährte Praktiken zurückzugreifen. Eine Praktik, die bei meinen Kunden sehr gut ankommt, ist die Grösse der Arbeit in T-Shirts-Sizes einzuteilen.
Hier ein Beispiel einer Skala von T-Shirt-Grössen, die ein Kunde letzte Woche entwickelt hat:
Wichtig ist, die Zahl z.B. 3 Tage repräsentiert nicht die Dauer, sondern den Aufwand der geleistet werden darf, damit diese Arbeit erledigt ist. Die T-Shirt-Grösse ist optimalerweise auf dem Arbeitszettel, welcher über das Kanban-Board wandert, sichtbar.
In diesem Beispiel für die Arbeit 15677 ist ein Aufwand von XL vorgesehen.
Dies hilft uns in einem Arbeitssystem auf einen Blick einzuschätzen, wieviel Arbeit den darin enthalten ist. Ein einzelner Arbeitszettel kann offensichtlich (nach der Skala von oben) von 1 Tag bis grösser 20 Tage Arbeit enthalten. Hier nur die Anzahl wahrzunehmen ergibt kein zuverlässiges Bild.
Beim Schätzen dieser T-Shirt-Grösse kann das Team miteinbezogen werden. Dies unterstützt den Dialog über die darin enthaltene Arbeit und das daraus resultierende gemeinsame Verständnis.
Setzt du heute bereits T-Shirt-Grössen im Arbeitssystem ein?
Über mich
2 Antworten
Du weißt, ich arbeite auch gerne nach Scrum, und hier geht’s wahrscheinlich um Poker und Backlog. Aber wenn bei dem Beispielkunden nach dem Schreiben der Epics immer noch T-Shirt-Größen oberhalb von S vorkommen, wäre meine Unterstellung, dass die Aufgaben nicht verstanden oder nicht genau genug in Unteraufgaben aufgesplittet sind. Eigentlich würde ich das schon bei Aufgaben unterstellen, die mehr als 3 Tage Aufwand sind.
Das merke ich vor allem an, weil ich das für einen der Kardinalsfehler halte, wenn Unternehmen neu mit Scrum arbeiten. Es ist natürlich cool, mit den groben Aufwänden planen zu können, aber Scrum ist keine Ausrede, Aufgaben nur grob zu umreißen und in eine Schublade mit der Aufschrift “13 – 20 Personentage” zu stecken. Vor dem Einplanen in die Sprints muss genau aufgeschrieben werden, was zu tun ist, und dabei kommt eigentlich _nie_ irgendwas mit mehr als 1-2 Tagen Aufwand raus (es sei denn, wir reden über langlaufende Aufgaben wie “2 Millionen Handzettel auf der Bogenoffsetmaschine drucken”). Bei Wissensarbeit ist alles über 1-2 Tagen ein Zeichen, dass etwas nicht stimmt.
Hoi Thorsten
Danke dir für deinen Kommentar.
Bei meinem Beispiel geht es nicht um Scrum. Es geht um komplizierte, hoch strukturierte Arbeit.
Ja, in einem Scrum Backlog muss die Story so geschärft werden, dass sie “verdaubar” fürs Team ist. Sprich, eine geeignete Grösse aufweisen und genügend Klarheit beinhalten, damit das Team damit arbeiten kann. Aber auch nicht zu viel Klarheit, da sonst zu viel “Vorarbeit” geleistet werden muss. Und genau das wollen wir ja im Scrum vermeiden :-). Mit einer höheren Teamreife und den richtigen Skills im Team können dann gerne auch grössere, komplexere Stories reingegeben werden. Und das Team übernimmt dann die Verantwortung, die Story kleinzuschneiden und zu verarbeiten. So ist jedenfalls mein Erlebnishorizont.