Wie gehen wir optimal mit Unterbrechungen in Scrum um?
Unterbrechungen in Scrum während des Sprints, also die notwendige Abweichung von dem im Sprint Planning aufgestellten Sprint Backlog, ist gar nicht so selten. Wir leben in einer unbeständigen Welt und wenn die Rahmenbedingungen komplex sind, dann treten Änderungen am Plan auf, mit denen wir umgehen müssen. Das Unterbrechungen in Scrum auftreten, da sind sich viele einig - doch wie gehen wir mit diesen konkret um?
Diese Fragestellung beleuchte ich in meinem Artikel, angereichtert mit den Erkenntnissen, die ich vom Scrum@Scale Training mit Jeff Sutherland in München erlangt habe. Es ging nur am Rande um Unterbrechungen in Scrum. Ich habe aber eine wichtige neue Erkenntnis zu meinen bisherigen Betrachtungen gewonnen.
Was sind Unterbrechungen?
Unter Unterbrechungen verstehe ich die Situation, dass ein Team etwas im Sprint Planning geplant hat und dann plötzlich aus irgendwelchen Gründen noch eine andere Aufgabe in diesem Sprint erledigen muss. Das sollte nicht vorkommen, aber in der Realität sieht das immer anders aus. Gerade wenn das Team eine bestimmte Sprintlänge wie zum Beispiel einen Monat nutzt, ist die Wahrscheinlichkeit hoch, dass auch Unterbrechungen in Scrum auftreten. Deshalb beziehe ich mich bei Unterbrechungen nun immer darauf, wenn etwas unvorhergesehenes im Sprint passiert, was ich nicht in meinem Sprint Backlog zu Beginn geplant hattee. Ein typisches Beispiel dafür sind Fehler, die umgehend behandelt werden müssen.
Wie kann ich Unterbrechungen in Scrum behandeln?
Zunächst gehe ich auf die beiden von mir praktizierten Möglichkeiten ein, eine Unterbrechung in Scrum zu behandeln. Zum Schluss möchte ich die Idee von Jeff Sutherland noch einmal aufgreifen und hier mit in diese Überlegungen mit einbringen.
Um Unterbrechungen in Scrum abzufangen drängt sich eine Möglichkeit sofort in den Vordergrund: das Arbeiten mit Puffern. Auch meine beiden Ansätze basieren immer auf einem Konzept eines Puffer. Wenn ich von so einem Puffer spreche meine ich damit eine bestimmte Zeit/Kapazität, die Im Sprint Planning bewusst nicht verplant und frei gehalten oder aber als bewusster Puffer-Platzhalter mitgeplant wird. Tritt nun eine Unterbrechung in Scrum auf, dann konsumiert diese Unterbrechung - und die damit verbundene zu erledigende Aufgaben - Zeit von genau diesem Puffer.
Puffer sind teuer!
Klingt alles plausibel finden Sie? Ja, ist es auch, nur Puffer haben auch Nachteile! Durch so einen Puffer erkaufe ich mir Sicherheit. Schauen wir uns die beiden Beispiele an:
Betriebswirtschaftlich gesehen, sind Puffer immer teuer und wenn ich sie nicht brauche sind sie Verschwendung. Ob Sie nun diese Entscheidung für oder gegen einen Puffer treffen ist eine wirtschaftliche Abwägung. Scrum selbst arbeitet ohne Puffer.
Puffer in der Kapazität des Teams
Wenn wir bereits wissen, dass wir mit Unterbrechungen konfrontiert werden, dann hilft es, wenn wir uns der eigenen Kapazität im Team klar werden. Was also schafft das Team, wenn es nicht unterbrochen wird? Dabei ist es zweitrangig, was für eine Kapazität wir im zu Beginn annehmen. Wichtig ist erst einmal nur, dass das Team diese kennt. In der Realität ist das oft bei gerade startenden Teams nicht so.
Wenn ich diese Kapazität kenne und vielleicht sogar noch historische Werte habe, wie ich die Unterbrechungen in Scrum bestimmen kann, dann ist es umso besser. Wenn ich diese nicht kenne, dann muss ich schätzen.
Was kann ich also tun? Die Lösung kann darin liegen, in einem Team mit einem Puffer in die Sprint Planung zu gehen. Ich plane nur das, was ich kenne. Zudem reserviere ich dann von der maximal möglichen Kapazität einen bestimmten Prozentsatz. Diesen beplane und betrachte ich nicht weiter. Alle unvorhergesehenen Aufgaben werden darin bearbeitet.
Die folgende Abbildung zeigt, wie Sie mit Unterbrechungen in Scrum umgehen können.
Puffer im Backlog
Letztendlich betrifft auch der Puffer im Backlog die Kapazität des Teams. Allerdings ist die Ebene dieser Puffersteuerung eine andere. Wenn ein Team beispielsweise mit Story Points arbeitet und eine durchschnittliche Velocity von 20 Story Points hat, dann könnte das Team einen "Platzhalter" von 5 Story Points im Sprint Backlog haben.
Damit sind ist die ganze Kapazität im Fokus der Sprint Planung.
Das Learning vom Training
Was mir gut zu den Unterbrechungen in Scrum von den Aussagen vom Jeff hängen geblieben ist, war die Aussage, dass diese Puffer von Sprint zu Sprint kleiner werden muss! Läuft der Puffer über, muss neu geplant werden und eine Anpassung vorgenommen werden.
Ich denke alleine das einmal im Kopf zu haben und dann so die eigene Implementierung zu überprüfen ist schon eine gute Möglichkeit zur Reflexion.
Velocity beinhaltet auch Interrupts
Im Scrum@Scale Guide 0.8 findet sich der Hinweis, dass die Velocity mit den Interrupts zu behandeln ist ( "Velocity for each team including buckets of where velocity is spent (e.g., interrupts, technical debt, etc.)"). Demzufolge ist die Version mit der User Story (oder dem Product Backlog Item) im Backlog die "richtige" Version.
Je länger ich über die beiden Versionen mir Gedanken mache, desto mehr finde ich den Platzhalter im Product Backlog besser, als das pauschale Berechnen einer Kapazität, die dann auch nicht mehr im Fokus ist. Dieses hat die folgenden Gründe, die ich gerne noch zur Diskussion stelle:
- 1Der Scrum Wert "Fokus". Durch den Fokus in einer Sprint Planung auf dem Event und dem Inhalt für den kommenden Sprint ist es essentiell, dass alles was im Fokus steht auch im Product Backlog und dann im Sprint Backlog abgebildet ist. Das ist bei der Platzhalter-Methode der Fall, denn es ist klar und sichtbar, dass eine bestimmte Kapazität im Sprint reserviert ist.
- 2Der Schmerz bleibt sichtbar. Wenn mit einem Platzhalter Product Backlog Item gearbeitet wird, dann ist jedem bewusst, dass diese Unterbrechungen stattfinden und diese sind sichtbar.
- 3Leichter Austausch durch Product Backlog Items möglich. Sollte eine Unterbrechung nicht erfolgt sein, so ist direkt klar, in welcher Größenordnung noch ggf. Product Backlog Items nachgezogen werden können. Bei einer Reservierung einer Kapazität besteht wahrscheinlich eher die Gefahr, dass Parkinsonsche Gesetz zuschlägt.
- 4Kapazität ist das, was ein Team auch leisten kann. Das Separieren von "planbaren" und "nicht planbaren" in einer getrennten Kapazität lässt den Blick von der gesamten Kapazität abrücken.
