Was ist das Sprint Health Gadget?
Das Sprint Health Gadget ist eines der vielen Gadgets, die Jira für das Dashboard zur Verfügung stellt. Es ist eine grafische Darstellung des Status Quo eines Scrum Teams, die dem geübten und erfahrenen Scrum Master ALLES über den Stand der Dinge während eines Sprints mitteilt.
Ja, daraus lässt sich auch ableiten, wie das Burndown Chart (in etwa) aussieht.
WHY – wozu braucht man es, das Sprint Health Gadget?
Um sich als Scrum Master – oder als RTE – einen möglichst schnellen und umfassenden Überblick über das Sprint-Geschehen zu machen.
Lesen für Anfänger
Als Scrum Master oder als Release Train Engineer fiel mein Blick immer zuerst auf die beiden Werte
Time elapsed und Work complete
War der Sprint schon weit fortgeschritten und die Menge der bereits abgeschlossenen Arbeit noch gering, deutete das auf eine Schieflage hin.
Ist die Hälfte – oder gar mehr – der Laufzeit eines Sprints bereits verstrichen und die Menge der abgeschlossenen Arbeit (Issues im Status Done) ist gering, ist die Wahrscheinlichkeit für das eine oder andere oder gar viele Defizite groß.
Die zwei gängigsten Erklärungensversuche – Ausreden – noch unerfahrener Scrum Master sind:
- Die werden erst nach / mit dem Review vom Product Owner auf Done gesetzt,
oder
- die werden erst gegen Ende des Sprints fertig.
Mal ehrlich, das Sprint Review ist eine Marketing-Veranstaltung auf der den Stakeholdern der Mehrwert präsentiert wird, den sie mit dem gerade fertiggestellten Increment bekommen werden. Ziel dieses Events ist es, dass die – also die Stakeholder – „la ola“ – die Welle – schlagen.
Die Abnahme eines Issues – einer User Story, einer Task, oder die Behebung eines Bugs – sollte durch den Product Owner zeitnah nach der Umsetzung erfolgen. Der muss doch wissen, ob er‘s gut und damit richtig gemacht hat. Warum damit bis zum Ende des Sprints warten?
Ist das Ergebnis nicht wie erwartet, also wie in der User Story beschrieben und / oder vom Product Owner gemeint, soll der Entwickler sich „gleich“ dran machen und es korrigieren. Wartet man damit bis zum Ende des Sprints, also bis zum Review,
- hat das Development Team keine Zeit mehr den Schiefstand zu beheben (vielleicht wäre es ja nur eine Kleinigkeit)
und
- der Entwickler ist an seinem Tun nicht mehr so nah dran, weil er zwischenzeitlich vielleicht schon ein paar andere Issues umgesetzt hat.
Der eklatante Scope Change
Wie kann so etwas geschehen? Wie ist das zu rechtfertigen?
Mögliche Ursachen:
-
- Nachdem der Sprint schon gestartet worden war, sind noch Issues – User Stories – in den Sprint Plan aufgenommen worden; nachträglich!
Frage: Warum das? Was war das für ein Sprint Planning? - Im Rahmen des Sprint Plannings wurden Issues in den Plan aufgenommen, für die noch nicht der Aufwand geschätzt war und die Schätzung wurde während des Sprints nachgeholt.
Frage: Wie kann man ohne jegliche Ahnung über den zu erwartenden Aufwand eine Sprint-Planung vornehmen? - Eine Aufwandsschätzung wird nachträglich maßgeblich verändert
Frage: Warum das, hat man vorher nicht sauber gearbeitet (geschätzt)?
- Nachdem der Sprint schon gestartet worden war, sind noch Issues – User Stories – in den Sprint Plan aufgenommen worden; nachträglich!
Was zu rechtfertigen wäre:
- Wider erwarten ist das Team mit der Implementierung des Plans kurz vor Ende des Sprints schon fertig geworden. Es wird noch eine kleine User Story nachgezogen. Man / das Team ist fleißig.
- Eine User Story wird aus dem Sprin Plan genommen, weil ein anderes Team mit den nötigen Vorarbeiten – der Umsetzung einer Dependency – doch nicht fertig geworden ist. Dafür wird eine andere User Story aus dem Backlog nachgezogen.
Die Burndown-Ableitung
Und wenn wir uns bereits in der Mitte des Sprints befinden und noch immer kein Grün (= Done) im Balken des Sprint Health Gadgets zu sehen ist, dafür aber viel Gelb (= Work in Progress), dann hat auch das Burndown noch keinen Sprung nach unten gemacht. Es ist anzunehmen, dass es – das Burndown Chart – eine lange horizontale Linie zeigt.
Farbenspiel
- BLAU = Issues, mit denen noch gar nicht angefangen wurde.
Alle noch in der Spalte To Do - GELB = Issues, an denen bereits gearbeitet wird.
Alle in den Spalten zwischen To Do und Done.
Die Issues könnten In Development, In Review, In Testing, etc. sein. Je nachdem, wie das Board aufgebaut ist. - GRÜN = Done.
Anmerkung: Die Zahl, die in den jeweiligen Balken steht, zeigt die Summe der geschätzten Aufwände der Issues an, die sich im jeweiligen Status befinden. Nicht die Anzahl der Issues.
Conclusio
Das Sprint Health Gadget ist ein wichtige Hilfsmittel um einen ersten und schnellen Überblick über das Geschehen während des Sprint-Verlaufs zu erhalten. Es bringt Transparenz ins Geschehen und ermöglicht damit einem Schiefstand entgegen zu steuern.
Siehe dazu auch: „Was ist ein Commitment wert, wenn …“
