Blick mit der Lupe auf die Datenlage

SAFe: Des RTE’s (Jira) Dashboard

Sind wir im Plan?

Das ist doch die wirklich interessante Frage, die der RTE im Rahmen eines Scrum of Scrums stellen muss, oder?

Als “Oberhäuptling” der Methode sollte es doch sein primäres Anliegen sein, durch den effektiven und effizienten Einsatz der Methode einen möglichst guten Projektfortschritt zu gewährleisten. Was aber häufig in Scrum of Scrums besprochen wird, ist …

Bla Bla Bla

  • Was hat das Team seit dem letzten Scrum of Scrums umgesetzt?
  • An was arbeitet es gegenwärtig?
  • Was sind die Impediments des Teams?

So sieht oftmals die Agenda – das Sprüchlein – aus, wenn denn die einzelnen Scrum Master reihum ihren Statusbericht kund tun.

Aber mal ganz ehrlich, …

  • kann der RTE mit den Erläuterungen darüber, an was die einzelnen Teams – vielleicht 12 an der Zahl – gerade arbeiten, etwas anfangen? Hat er den inhaltlichen Tiefgang, der ihn tatsächlich verstehen lässt an was 80 oder mehr Developer innerhalb eines Zeitraumes von vielleicht sechs bis zehn Wochen gerade arbeiten?
  • interessieren den RTE die Impediments, um die sich der einzelne / jeweilige Scrum Master zu kümmern hat?

Wenn man sich vergegenwärtigt, dass der RTE der oberste Experte der Methode ist, dann kann man wohl nur schwerlich behaupten, dass er sich groß um das Inhaltliche – das Was – kümmern sollte oder auch nur die Zeit dazu hat. Das ist doch wohl eher die Aufgabe der Product Manager und der Product Owner, oder?
Und warum sollte der RTE sich groß mit den Impediments der einzelnen Scrum Master befassen, wenn sich diese (noch) auf der Teamebene befinden?

Rein aus Neugierde? Nur um es zu wissen?

Des RTE’s Dashboard

Das Dashboard verschafft dem RTE einen ersten Überblick über das Projektgeschehen. Es soll keinesfalls das Scrum of Scrums obsolet machen, stellt für ihn aber eine gute “Vorbereitung” auf das Meeting – das Scrum of Scrums – dar.

Anmerkung: Gerüchten nach soll es Scrum Master geben, bei denen (in deren Teams) immer alles gut ist, auch wenn die Zahlen etwas anderes sagen.

Der Status Quo jedes einzelnen Teams lässt sich aus dem Agile Sprint Health Gadget ablesen und ein Dashboard, das die Sprint Health Gadgets aller Teams des ARTs (Agile Release Train) anzeigt, gibt einen ziemlich aussagekräftigen und vor allem schnellen Überblick über das gegenwärtige Geschehen.

Time elapsed & Work completed

Diese beiden Werte geben einen ersten Eindruck darüber, ob ein (Scrum) Team im Plan ist.

Es sind bereits 54 % der Dauer des Sprints um und es sind schon 43 % des Sprint Plans umgesetzt. Das sieht garnicht schlecht aus, oder? 4 Tage sind vom Sprint ja noch übrig.

Gerade sind User Stories in Arbeit, für die in Summe ein Aufwand von 5 Story Points geschätzt worden war. Mit User Stories, für die in Summe ein Aufwand von 3 Story Points geschätzt worden war, ist noch nicht angefangen worden.

Wie schon gesagt, sieht gar nicht schlecht aus. Das Sprint-Ziel könnte erreicht werden.

Das ist aber noch ein Scope Change von 27 % und der ist erklärungsbedürftig.

Siehe auch: Blog über die Kunst das (Jira) Health Gadget richtig zu lesen.

Scope Change

Ein Scope Change kann durch folgende Vorkommnisse zustande kommen:

  1. es wurde erst nachträglich – nach Sprint Start – eine Aufwandsschätzung durchgeführt
  2. es wurde eine ursprüngliche Aufwandsschätzung korrigiert
  3. es wurden nachträglich – nach Sprint Start – Issues (mit Aufwandsschätzung) in den Sprint Plan aufgenommen

Gerade sind User Stories in Arbeit, für die in Summe ein Aufwand von 5 Story Points geschätzt worden war. Mit User Stories, für die in Summe ein Aufwand von 3 Story Points geschätzt worden war, ist noch nicht angefangen worden.

Wie schon gesagt, sieht gar nicht schlecht aus. Das Sprint-Ziel könnte erreicht werden.

Das ist aber noch ein Scope Change von 27 % und der ist erklärungsbedürftig.

Siehe auch: Blog von der Kunst das (Jira) Health Gadget richtig zu lesen.

Anmerkung: Ein Scope Change kann natürlich auch einen negativen Wert aufweisen, wenn

  1. eine ursprünglich vorgenommene Aufwandsschätzung nachträglich – nach Sprint Start – nach unten korrigiert wurde
  2. Issues nachträglich aus dem Sprint genommen wurden

Solange man einen Scope Change legitim begründen kann, ist er nichts Schlechtes. Wenn die Begründung aber hinkt, …

Eine hinkende Begründung wäre zum Beispiel: “Das haben wir erst nachträglich geschätzt.”

Wie kann man denn ein Sprint Planning – oder PI Planning – durchführen, wenn man keine Ahnung darüber hat, wie viel Aufwand in etwa die Umsetzung eines Issues macht?

Eine passende Begründung für einen Scope Change wäre dagegen: “Da das andere Team die notwendige Vorarbeit für diese User Story nicht planmäßig – gemäß PI Planning – abgeschlossen hat und auch nicht zu erwarten ist, dass das zeitnah geschieht, haben wir das Issue aus dem Sprint genommen. Dafür wurde eine andere Story aus dem Product Backlog nachgezogen.”

Oder

Sofern das Team – wider erwarten – einen oder gar zwei Tage vor Sprint-Ende mit der Umsetzung des Sprint Plans fertig geworden ist, kann es auch ruhig noch eine oder zwei kleine User Stories aus dem Product Backlog zur Umsetzung im gegenwärtigen Sprint nachziehen. Auch das ist ok und der Product Owner würde sich bestimmt darüber freuen.

Da der gesamte Sprint aber einen Umfang von 14 Story Points hat, sollte schon die Frage gestellt werden, wie es gleich zu einem Scope Change von 27 % kommen konnte?

Conclusio

Das RTE Dashboard wird keinesfalls das Scrum of Scrums obsolet machen. Es soll nur schon einmal einen ersten – aber zumeist doch ziemlich eindeutigen – Hinweis auf das Projektgeschehen aufzeigen.

Sollten Scrum Master entgegen der Aussage des Dashboard den Fortschritt der Implementierung als zufriedenstellend oder gar perfekt bezeichnen, sollte der RTE das kritisch hinterfragen.
Weiterhin ist wichtig, dass ein …

Status Quo KEINE Maßnahme zur Optimierung

darstellt. Sofern der vorgegebene Zielerreichungsgrad nicht annähernd erreicht wird, geht die Arbeit des RTE und seiner Scrum Master erst richtig los. Es gilt die Ursachen dafür zu finden und Abhilfe zu schaffen. Das kann viel, sehr viel Arbeit sein. Die Zeit sich darüber Gedanken zu machen, was das Projekt inhaltlich umsetzt, ist dann oft nicht mehr gegeben.

Sie wollen Ihr Know How erweitern oder Ihren RTEs ein Advanced Training zukommen lassen? Kontaktieren Sie uns.

Allgemein,Tools
Keine Kommentare

Share This Story, Choose Your Platform!

Über den Autor:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Bitte füllen Sie dieses Feld aus.
Bitte füllen Sie dieses Feld aus.
Bitte gib eine gültige E-Mail-Adresse ein.
Sie müssen den Bedingungen zustimmen, um fortzufahren.