Welche Status Sie in Ihrem Scrum Board tatsächlich brauchen und warum Sie NUR mit diesen erfolgreich sein werden, erfahren Sie hier.
Zunächst mal eines vorweg: Der Plural von Status ist Status, mit langem „uu“ gesprochen aber gleich geschrieben. Ja, ich habe es vor langer Zeit auch mal gegoogelt, es hat mich 17 Sekunden gekostet, aber mein Leben bereichert. Ich erwähne dies nur für all jene, die sonst ein Plural wie Stati oder Statusse erwartet hätten und beim Lesen des Artikels sonst verwirrt sind.
Wir sind in Scrum ja sehr bemüht, die Dinge einfach zu halten und uns auf das Wesentliche zu konzentrieren und meist gelingt es uns auch recht gut.
Und dann aber tauchen plötzlich und wie aus dem Nichts JIRA Workflows und Scrum Boards mit teilweise dutzenden Status und Workflowverzweigungen auf. Sehen Sie sich mal dieses Bild an.
In diesem Scrum Board gibt es viel zu viele Status. Das reinste Chaos. Kein Wunder, dass sich niemand mehr zurecht findet.
Bedauerlicherweise wird es einigen sogar vertraut erscheinen aber in Wirklichkeit ist es ein Albtraum.
Dies ist der Workflow eines realen Kundenprojektes, kein Scherz. Je größer die Projekte sind, desto komplexer ist in der Regel auch der Workflow.
Nein. Im Gegenteil. In einem langlaufenden Projekt mit über hundert Entwicklern, wo wir nach Konsistenz in der Arbeitsweise bemüht sind und für ein hohes Maß an Effektivität täglich kämpfen, können solche Workflows im Scrum Board Teams ziemlich aus dem Tritt bringen.
Ich habe oft Teammitglieder gefragt ob sie mir denn mal den Unterschied zwischen den Status „resolved“, „done“ und „closed“ beschreiben können. Zweifellos könnte man eine plausible Erklärung finden, aber die Realität ist doch oft die, dass diese Status bunt gemischt im Backlog auftreten und fünf Personen ebenso viele unterschiedliche Interpretationen dieser Status vorlegen.
Während Projektorganisationen oft dabei sind, den ganzen Tag neue Rollen zu erfinden und viele dieser Rollen für sie vielleicht sogar Sinn machen, kennen wir in Scrum nur drei Rollen.
Natürlich gab es in zwei- oder mehrjährigen Wasserfall-Projekten, die über die gesamte Zeit ja nur eine lange Iteration durchlaufen, viele Status. Die Statusflut in Scrum ist wie eine Reminiszenz an diese alten Wasserfall-Kulturen.
Ich mache es heute nicht so spannend und nehme meine Empfehlung mal gleich vorweg.
Mit „Open“, „in Progress“ und „Done“ kommen Sie durch fast jedes Projekt in fast jeder Organisation und passieren sogar und wenn es sein muss alle möglichen Quality-Gates.
Nehmen Sie meinetwegen der besseren Übersicht halber noch das Flag „on hold“ dazu, aber das war’s dann auch. Warum?
Es werden lediglich diese Status im Scrum Board benötigt: To do, In Progress, On hold, Done.
Nehmen wir hier als Beispiel den sicher beliebtesten- und wahrscheinlich sogar überflüssigsten Status „In Testing“ exemplarisch für viele anderen Status neben den drei oben genannten.
Wann immer ich den Status „In Testing“ in einem Scrum Board sehe, kann ich mir einfach die Frage nicht verkneifen, warum wir nicht auch einen Status „In Thinking“, „In Frontend-Development“, „In CSS-Refactoring“, „In Lunchbreak“ oder was auch immer haben.
Es wird hier suggeriert, dass Testen offenbar nicht zur Implementierung gehört und dies ist tatsächlich und meist ernst gemeint auch die Antwort, die ich bekomme.
„Die Implementierung ist abgeschlossen und jetzt muss nur noch getestet werden“ (mit Betonung auf „nur“).
Oh je. Interessanterweise ist bisher kaum jemand auf die Idee gekommen, den Status „In Documentation“ einzuführen. Ach so, in Scrum wird ja nicht mehr dokumentiert.
(Verzeihen Sie meinen Sarkasmus)
Testen ist kein Status, sondern eine Aktivität.
Und zwar eine Aktivität, die genauso geplant, assigned, ausgeführt, getrackt und abgeschlossen wird, wie jeder andere Implementierungsschritt, für die ganz selbstverständlich auch Subtasks erstellt werden.
Gleiches gilt auch für Pull-Requests, Tech-Invests, Dokumentieren, usw. die ebenfalls oft als Status, statt als Subtasks geführt werden.
Warum ist es nicht egal, ob Status einer Story oder Subtask innerhalb der Story? Dafür gibt es gleich mehrere Gründe.
Einen Subtask kann ich schätzen, planen und tracken.
Ich kann Statistiken darüber erstellen, wieviel Zeit durchschnittlich für Tasks, die z.B. netto-Wertschöpfung betreffen, aufgewendet wird und wieviel Zeit für alles andere.
Ein Status kann das nicht.
Macht es zum Beispiel Sinn, Testautomatisierung einzuführen kann ich leichter beurteilen, wenn ich mal alle Subtasks zusammenzähle, die sich mit Testen beschäftige und die getrackten Zeiten auswerte.
Das Gleiche mit Subtasks, die z.B. alles an „continuous integration (CI)“ Aufwände betreffen, um zu sehen, ob wir denn die richtige CI-Strategie haben.
In einem meiner Projekte kam dabei die für alle etwas überraschende Tatsache zum Vorschein, dass wir 28% für reine Implementierung, also netto-Wertschöpfung haben, aber knapp über 30% für CI und weitere 20% für manuelles Testen (dokumentiert wurde da offenbar schon gar nicht mehr). Da war schnell klar, dass sich etwas ändern muss, vor allem aber auch war klar, was zuerst und warum.
Dem Setzen eines Status für eine Story kann ich nicht ablesen, wie lange die Story in diesem Status verweilen wird.
Aber genau das interessiert mich. Ich möchte wissen, wann eine Story voraussichtlich fertig sein wird und was hier noch zu tun ist. Bei einem Status weiß ich ja noch nicht mal genau, was noch alles folgt, insbesondere wenn es davon gleich mal ein halbes dutzend Status oder mehr gibt, die durchlaufen werden können, aber manchmal auch nicht durchlaufen werden müssen.
Dann wird oft ins Feld geführt, dass die Status im Sprint-Backlog zu mehr Übersichtlichkeit führen und ich auf einen Blick ablesen kann, wie es um die Stories und den Sprint steht.
Das ist doch aber wirklich ein Witz! Seien wir mal ehrlich. Wenn Sie gutes Scrum machen und ein möglichst kleines Team haben, sagen wir mal 6 Leute und einen möglichst kurzen Sprint, idealerweise eine Woche, meinetwegen auch zwei. Dann haben Sie in der Regel so zwischen 5 und 10 Stories im Sprint, die ja von oben nach unten abgearbeitet werden sollen. Dazu kommen noch ein paar Bugs aus dem letzten Sprint, auch so zwischen 5 und 15, je nach Größe und Umstände.
Wenn ich als Product Owner mal sehen möchte, wie mein Team so arbeitet und ich die Swimlanes meines Sprint Backlogs im Scrum Board mit nur drei Status betrachte, dann brauche ich maximal 30 bis 90 Sekunden, um zu sehen wie es steht. Und das mache ich natürlich täglich bis zweimal täglich.
Das Verwalten der Flut von Status – wenn es denn überhaupt vom Team ordentlich gepflegt wird – dauert definitiv um ein Vielfaches länger.
Da ich – und das ist ja auch Realität – gar nicht darauf vertrauen kann, ob die Status immer richtig gepflegt sind, bringt das Ganze eher wenig.
Und die Nachteile von Status versus Subtasks gehen noch weiter. Teams sind gehalten, Stories möglichst schnell abzuschließen.
Es geht hier weniger um Effizienz als mehr um Effektivität.
Wir sehen es lieber, dass mehrere Entwickler eine Story gemeinsam abschließen, als dass fünf Entwickler parallel an fünf Stories arbeiten.
Denn es wäre fatal, wenn sie alle nicht fertig werden und wir am Ende eines Sprints mit komplett leeren Händen dastehen.
Also werden idealerweise Stories nicht nur vertikal implementiert, sondern auch von mehreren cross-funktional agierenden Entwicklern. Da kommt es dann schon mal vor, dass z.B. die iOS-Implementierung schon getestet werden kann, während die Android Jungs und Mädels noch arbeiten.
Welchen Status also bekommt die Story?
Das Setzen von Status impliziert also auch immer eine vollständig sequentielle Abarbeitung einer Story, wie wir es aus Wasserfall-Prozessen kennen.
Dann wundert es natürlich auch nicht, dass Einige Scrum immer mal wieder mit Micro-Wasserfall übersetzen, was der Idee nach ja grundfalsch ist und einer solchen Fehlinterpretation dann auch praktisch Vorschub leistet.
Alles, was für die vollständige-, vertikale- und end-2-end Implementierung einer Story benötigt wird, sind Aktivitäten und sollten auch so behandelnd in Subtasks gekleidet werden.
Testen, CI, Review sind den Implementierungstasks dabei genau gleichwertige Aktivitäten.
Subtasks bieten die Möglichkeit der Planung, der Schätzung, des Zuweisens, des Kommentierens, des Beschreibens, etc. Status können das alles nicht.
Eine Story ist solange „in Progress“ bis wirklich alles erledigt ist.
Damit ist auch alles gesagt. Im Verlauf eines (hoffentlich) kurzen Sprints wollen wir wissen, ob an dieser Story schon gearbeitet wird und ob es hier ein Problem gibt („on hold“) oder nicht.
Weiterführende Informationen sehe ich dann im Implementierungsplan, repräsentiert durch die Subtasks.
Und vergessen wir nie, dass ein Scrum Board die Arbeit eines möglichst kleinen Teams für die Dauer möglichst kurzen Sprint organisieren soll.
In großen Organisationen mit mehreren Duzend bis mehreren hundert Entwicklern gibt es im Rahmen von agilen Transformationen sehr bald Fragen und Diskussionen über die richtige Skalierungsstrategie.
Mit der WSJF Methode werden PI Plannings zum Kinderspiel und effektiver als je zuvor. Hier geht’s zum kostenlosen Step-by-Step Guide und WSJF Excel Template
Was ist der Unterschied zwischen einer vertikalen und horizontalen Organisation und wie bildet man eine vertikale Organisationsstruktur? Roadmap für agile Transformation + Case Study
Für Scaled Agile Organisationen kann es frustriererend sein, wenn Projektmanagement Tools ihre Prozesse nicht unterstützen.
Daher haben wir scagile als eine App entwickelt, die aktiv agile Best-Practices fördert und mit der ein Value Flow über die gesamte Organisation hinweg etabliert wird.
