Theorie "Scrum Charts"
Wie Sie bestimmt schon festgestellt haben, sind wir nun mit unserem Weblearning mit der Sprint Retrospective am Ende eines Sprints angekommen. Vor Ihnen liegen aber noch zwei weitere Kapitel: Scrum Charts und die Release Planung.
In diesem Kapitel werden Sie mehr über Scrum Charts erfahren.
Charts im Sprint¶
Um zu visualisieren wo sich die Developer im Sprint gerade befinden, gibt es zwei unterschiedliche Charts, die Anwendung finden können. Das am häufigsten verwendete Chart ist das Sprint Burn-Down-Chart. Das Sprint Burn-Up-Chart stellt eine Alternative zum Sprint Burn-Down-Chart dar. Ein weiteres Chart - welches allerdings nicht den aktuellen Stand des Sprints darstellt - ist das Velocity-Chart.
Sprint Burn-Down-Chart¶
Jeden Tag werden die Arbeitsstunden der noch offenen Tasks im aktuellen Sprint geschätzt und anschließend in das Sprint Burn-Down-Chart eingetragen. Es entsteht das Bild einer nach unten führenden Treppe. Um die Arbeitsstunden der noch offenen Aufgaben schätzen zu können, wird der Sprint Backlog genutzt. Anhand dessen erkennen Sie direkt, welche User Stories schon "Done" und welche Tasks noch offen sind. Die Tasks, die sich in "To Do" und "WiP" befinden, sind noch offen und müssen geschätzt werden. Sobald die offenen Tasks geschätzt und in das Sprint Burn-Down-Chart eingetragen wurden, werden diese mit einer linearen Ideallinie bei gleichmäßiger Abnahme der unfertigen Tasks verglichen.
Was ist eine lineare Ideallinie?
Eine lineare Ideallinie ist eine Linie, die linear von Tag 1 bis Tag 21 (bei einem vierwöchigen Sprint) verläuft. Sie beginnt bei Tag 1 und schneidet dort die Ordinate, wo die geschätzte Arbeitszeit aller Tasks liegt. Sie verläuft linear abwärts, bis sie am Tag nach Sprint-Ende (Tag 21) die Abszisse schneidet. Im Idealfall sollten die Tasks so erledigt werden, sodass am Ende des Sprints keine Tasks mehr offen sind. Die lineare Ideallinie dient dem Vergleich zwischen dem 'Burn-Down auf dem Papier' und dem tatsächlichen Burn-Down.
Sollte sich ergeben, dass das Team das geplante Arbeitspensum bis zum Ende des Sprints nicht erledigen konnte, wird dieses im nächsten Sprint verringert bzw. im umgekehrten Fall erhöht.
Sprint Burn-Up-Chart¶
Eine Alternative zum Sprint Burn-Down-Chart ist das Sprint Burn-Up-Chart bei welchem die Arbeitsstunden der erledigten Tasks aufgetragen werden und somit ein aufwärtsweisendes Diagramm entsteht. In diesem Fall werden nicht die geschätzten Arbeitsstunden abgetragen, sondern die Arbeitsstunden, die tatsächlich benötigt wurden, um eine Aufgabe zu beenden. Das Diagramm beginnt bei null und endet an Tag 20 (bei einem vierwöchigen Sprint). Auch hier kann eine lineare Ideallinie gezogen werden: Beginnend im Ursprung (Tag 0 / Arbeitsstunden 0) und sie endet bei Tag 20 in Höhe der geschätzten Arbeitsstunden. Falls die geschätzten Arbeitsstunden von den tatsächlichen Arbeitsstunden abweichen, sollte, wie oben beschrieben, das Arbeitspensum im nächsten Sprint verringert oder vergrößert werden - oder die Schätzfähigkeiten sollten verbessert werden.
Warum ist das Sprint Burn-Down-Chart beliebter?
Da das Sprint Burn-Down-Chart mit der Summe aller Arbeitsstunden beginnt und die verbleibenden Arbeitsstunden im Verlauf des Sprints immer weniger werden, kann dies einen motivierenden Effekt auf die Developer haben. Sie können Tag für Tag sehen, was sie schon geschafft haben und dass die Tasks immer weniger werden.
Velocity-Chart¶
Im Gegensatz zu den beiden obengenannten Charts stellt das Velocity-Chart nicht die Tasks, die schon fertiggestellt bzw. noch fertigzustellen sind, dar, sondern es ist die visuelle Darstellung der Entwicklungsgeschwindigkeit. Eine zentrale Rolle spielen hier die Story Points.
Erinnern Sie sich noch, was Story Points sind?
Der gefühlte Arbeitsaufwand und die Wertigkeit einer User Story. Beeinflusst werden können Story Points bspw. durch Unsicherheiten, durch die Menge und die Komplexität der Arbeit. Sie sind weder monetär noch zeitbasiert, sondern sie stellen selbst die Maßeinheit dar, um die Product Backlog Items schätzen zu können.
Die Story Points sind wichtig, um die Velocity zu ermitteln, denn die Velocity wird berechnet, indem die Summe, der bisherigen Story Points durch die Anzahl der bisherigen Sprints geteilt wird. Um daraus ein Velocity-Chart anzufertigen, benötigt man wiederum zwei Kennzahlen: die geschätzte Velocity pro Sprint und die realisierte Velocity pro Sprint.
Nun können Sie für jeden Sprint zwei Säulen in ein Diagramm eintragen: Die geschätzte und die umgesetzten Velocity. Anhand des Velocity-Charts können sie für künftige Sprints die Velocity besser einschätzen.
Abweichungen von der Vorhersage zur Realität
Wenn die vorhergesagte und die tatsächliche Velocity voneinander abweichen, dann kann diese Information bei der zukünftigen Sprintplanung berücksichtigt werden. Aber nur, weil beispielsweise bei den ersten Sprints die geschätzte Velocity stark von der tatsächlichen Velocity abgewichen ist, heißt dies nicht, dass das immer der Fall sein wird. Die Erkenntnisse des Velocity-Charts sind nicht in Stein gemeißelt. Außerdem sollten diese Erkenntnisse niemals dazu genutzt werden, um unterschiedliche Teams von Developern miteinander zu vergleichen.
Release Burn-Down-Chart¶
Ein Chart auf Ebene des Gesamtprojekts, ist das Release Burn-Down-Chart. Dieses beschreibt den aktuellen Projektfortschritt bzw. den verbleibenden Arbeitsumfang im Vergleich zur linearen Ideallinie.
Mit dem Release Burn-Down-Chart lässt sich der Zeitpunkt eines Release ermitteln, sobald
- die Velocity der Developer bekannt ist oder gut abgeschätzt werden kann und
- die Gesamtzahl der für das Release notwendigen Einträge im Product Backlog stabil ist.
Anhand einer Ideallinie kann unter Berücksichtigung der Gesamtsumme der Story Points, die für den gewählten Release abzuarbeiten sind, und der Velocity ein Schnittpunkt zwischen der Ideallinie und der X-Achse gefunden werden.
Damit kann abgeschätzt werden, nach welchem Sprint ein Release möglich ist. Sollte sich herausstellen, dass der Zeitpunkt aufgrund zu vieler Einträge im Product Backlog (oder wegen geringerer Velocity als geplant) nicht eingehalten werden kann, so muss der Umfang der Einträge im Product Backlog gekürzt werden, um den Zeitpunkt halten zu können.
Beachten sie folgendes bei der Erstellung des Release Burn-Down-Charts:
- Arbeitsgrundlage sind die zu Beginn des Projektes abgeschätzten Aufwendungen für die Umsetzung der Einträge im Product Backlog.
- Y-Achse: Summe der Aufwände in Story Points
- Geschätzte und summierter Punktewert aller für das Release relevanten Einträge im Product Backlog
- X-Achse: Anzahl der Sprints
- Basierend auf der Velocity der Developer
Ideallinie und Trendlinie
Neben der linearen Ideallinie, können Sie im Release Burn-Down-Chart auch eine Trendlinie einfügen. Im Gegensatz zur Ideallinien, zeigt die Trendlinie nicht den idealen Verlauf, sondern den geschätzen Verlauf, basierend auf vergangene Sprints. Das heißt, falls die Velocity langsamer war, als geschätzt wurde, und in jedem Sprint weniger Story Points als erwartet umgesetzt wurden, wird die Trendlinie die X-Achse weiter hinten schneiden, als die Ideallinie. In diesem Fall werden voraussichtlich mehr Sprints als geplant nötig sein, bevor releast werden kann. Aber auch diese Linie ist mit Vorsicht zu genießen: Sie spiegelt nur den aktuellen Trend wider - wenn die Developer aber in den nachfolgenden Sprints eine andere Velocity haben, als während der ersten Sprints, dann kann sich das Releasedatum wieder verschieben. Daher sollte die Trendlinie nach jedem Sprint überprüft und ggf. angepasst werden.