Erfolgreicher mit diesen 3 Status in Ihrem Scrum Board

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.

Status Chaos eines Scrum Boards
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.

Aber muss das sein?

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.

Scrum Training

Agile in a Day

Wir trainieren Ihr Team, coachen Ihre Stakeholder und führen Ihr Projekt zum Erfolg!

Drei Status im Scrum Board genügen

Ja, sie lesen richtig. Drei.

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?

Wesentliche Status im Scrum Board: To do, In Progress, On hold, Done
Es werden lediglich diese Status im Scrum Board benötigt:
To do, In Progress, On hold, Done

„Testing“ ist kein Status

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.

Was ist der Unterschied zwischen Status und Subtask?

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.

Und die Übersichtlichkeit?

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.

Scrum Sprint Länge
Scrum Sprint: Warum 1 Woche effektiver ist
Warum ein 1-wöchiger Sprint viel effektiver ist und die Velocity Ihres Teams enorm steigern kann, erfahren Sie hier.

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.

Status vs. Subtasks

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.

Wasserfall vs. Scrum
Wasserfall vs. Scrum oder Effizienz vs. Effektivität
Scrum ist ein Kompromiss, den wir eingehen, wenn wir keine perfekte Welt vorliegen haben, aber dennoch ein Projekt erfolgreich durchführen wollen.

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.

Fazit

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.

Ein solcher Sprint ist definitiv zu kurz für ein halbes Dutzend Status.

2 Comments

  • klaus
    Posted 11. Juni 2019 06:25 0Likes

    Lieber Herr Jung,
    ich verstehe Ihren Schmerz. Interessant ist natürlich auch die Korrelation zwischen Sprintlänge und Anzahl der Status. Wenn Ihre CTO tatsächlich die Zeit haben 6 Status zu pflegen, dann sind oft die Sprints schon zu lang. Versuchen Sie mal 5 oder 6 Status in einem einwöchigen Sprint zu pflegen und Sie merken, wie absurd die Angelegenheit wird. Bei einem dreiwöchigen Sprint oder noch länger, kann man dem Gebrauch von mehr Status, den Wunsch nach mehr Kontrolle und Transparenz ablesen. Meist resultiert dies aber im genauen Gegenteil und eine Verkürzung der Sprints wäre wesentlich effektiver. CTO klingt dann ja auch immer nach Stakeholder. Die Status sind eigentlich nur für das „selbstorganisierte“ Scrum-Team. Nur das Team also entscheidet, wieviele Status es für einen erfolgreichen Sprint benötigt.
    beste Grüße,
    Klaus Riedel

  • Reinhard Jung
    Posted 8. Mai 2019 23:16 0Likes

    Mal ’ne klare Ansage. (i-like)
    Ich hatte bisher meist 6 (Anfragen[Tickets/Ideen per E-Mail], Offen[open], In Arbeit[in process], Im Test[Tickets welche die Kunden testen können und anschliessend -von ihnen- in „Erledigt“ geschubst werden], Erledigt[Von Kunden – aus „Im Test“], Rückfragen[on hold/Noch zuklären]) und bin dabei schon bei den meisten CTO gegen de Wand gelaufen 🙁

Leave a Comment

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.