Organisation des Sprints verbessern - Das Sprint-Canvas

Geschrieben von Sven Hary veröffentlich am in der Kategorie Agiles Arbeiten
 "Noch ein Canvas? Ist das nötig? Ich hab doch schon das Business Model Canvas, Value Proposition Canvas, mein Experiment Board und das Product Canvas. Meine Wand ist voll – soll ich noch Platz für das Sprint-Canvas schaffen?"

Ja! Hier erkläre ich dir, warum.

Sorry - in German! Go to the English abstract and free download of the Sprint Canvas.

----

 

Du wunderst dich, warum es am Ende eines Sprints oft Stress gibt, das "Commitment" nicht gehalten wird und das Team und der Product Owner immer unzufriedener werden?
Kommt dir einer oder mehrere der folgenden Punkte bekannt vor?

  • Absprachen aus dem Planning wurden vergessen – "Eigentlich wollte sich doch XY noch um ... kümmern.".
  • Der Product Owner verursacht Sprint Scope Creep.
  • Ein Team-Mitglied hat zwei Tage eine Fortbildung und kann nicht am Sprint-Ziel arbeiten. Das hatte keiner auf dem Schirm.
  • Ein anderes Team-Mitglied nutzt seine Home-Office-Tage und ist an zwei Tagen nicht im Haus - blöd für ein Refinement-Meeting oder sinnvolles Pair-Programming, denn an den nächsten Tagen hatte jemand anderes Home-Office.
  • Im Laufe des Sprints achtet keiner auf die Maßnahmen, die in der Retro beschlossen wurden. Nach drei Tagen kann sie keiner mehr wiedergeben.
  • Während der Retrospektive erinnert sich keiner mehr an die erste Sprint-Woche: "War doch Alles in Ordnung".

 

Ich kenne diese Punkte nur zu genau und habe als Scrum Master lange nach einer Lösung gesucht, wie ich die Absprachen aus Retros, Plannings und sonstige relevante Informationen für das Team sichtbar machen kann. Die Idee eines Canvas ist da natürlich im agilen Umfeld nicht neu (siehe oben), aber vielleicht auch nicht unbedingt schlecht.

Die Vorteile sind:

  • Relevante Daten an zentraler Stelle transparent und für jeden sichtbar festgehalten.
  • Auch gern vergessene "triviale Dinge" werden festgehalten.
  • Gute Basis für eine Reflektion (muss nicht zwingend eine Retrospektive sein, kann auch "nur" für den Scrum Master sein).
  • Erhöhte Verbindlichkeit durch gemeinsam aufgeschriebene, sichtbare Fakten.

 

Hier also mein Entwurf für das Sprint-Canvas:

Sprint Canvas Preview 

 

 

Die Bereiche des Canvas - und warum sind sie vorhanden?

1. Sprint-Ziel

Das Sprint-Ziel ist Bestandteil des Scrum Guides und ist meiner Erfahrung nach ein stiefmütterlich behandeltes Thema. Warum setzen wir welche Anforderungen in einem Sprint um? Was für einen Gewinn bringt das für den Kunden? Viele Teams können diese Fragen nicht beantworten - leider oft genug auch der Product Owner nicht. Das Sprint-Ziel ist für sie eher "Das zusammengestellte Arbeitspaket des Product Owners (=alle Items im Sprint Backlog) umsetzen."

Dies jedoch ist kein Sprint-Ziel. Ein Sprint-Ziel sollte dem Team eine Richtung vorgeben, was im Sprint erreicht werden soll. Ein Sprint-Ziel kann erreicht sein, auch wenn einzelne Stories/Tasks nicht abgeschlossen wurden. Ein Sprint-Ziel ist ein erreichbares Ziel, dessen Sinn und Zweck alle verstanden haben (Tipp: Am Ende des Daily Scrums ein kurzes Daumen-Voting: "Erreichen wir das Sprint-Ziel?").

 

2. Improvements / Experimente

Wenn wir wirklich agil unterwegs sind, versuchen wir uns kontinuierlich zu verbessern und Prozesse zu optimieren. Diese Herangehensweise, des "Continuous Improvement Process", geht auf die japanische Arbeitsphilosophie Kaizen zurück und strebt eine andauernde Verbesserung an. Der Ort, an dem das geschieht ist natürlich die häufig praktizierte Retrospektive - aber nicht nur. Jeden Tag sollten auch kleine Dinge auffallen, die man verbessern kann. Auch das Daily Scrum kann für den "Inspect&Adapt"-Prozess genutzt werden.

Trotzdem oder gerade deshalb ist es wichtig, Vorhaben, Experimente, Verbesserungsmaßnahmen schriftlich festzuhalten UND transparent zu machen. Die letzte Änderung im Scrum Guide versucht dies durch die Vorgabe, dass das Sprint Backlog mindestens eine Verbesserung beinhalten soll, die in der Retrospektive entwickelt wurde. Ergänzend dazu kann das im Canvas festgehalten werden und ggf. mit ein paar Hintergrundinfos ergänzt werden. Das Canvas sollte ja nicht zu weit vom Task-Board entfernt hängen ;).

So wird sichergestellt, dass Alle jederzeit sehen, was am Prozess/der Zusammenarbeit verbessert werden soll.

 

3. Team-Event

Dieser Punkt überrascht vielleicht den ein oder anderen, wird aber gerne vergessen. Wann hat das Team das letzte Mal etwas zusammengemacht, das NICHT mit dem Sprint-Ziel zu tun hatte? Gemeinsam gekocht, gegessen oder einfach mal zusammen ein Bier getrunken?

Es muss nicht zwangsweise in jedem Sprint ein Team-"Event" stattfinden, aber das Datum des letzten Events erhöht die Aufmerksamkeit und lässt uns nicht vergessen, dass wir auch zusammen feiern dürfen! Wenn ein konkretes Team-Event eingetragen ist, ist auch dies transparent und kann ggf. andere Teams inspirieren!

 

4. Ø-Velocity der letzten drei Sprints

Immer wieder werde ich davon überrascht, dass Teams ihre eigene Velocity nicht kennen. Das könnte man jetzt auf den Scrum Master schieben, aber ich denke, dass diese abstrakten Zahlen auch nicht bei jedem im Kopf hängen bleiben. Schon gar nicht eine durchschnittliche Velocity der letzten x Sprints.

Gemeinsam mit den Abwesenheiten gibt diese Zahl dem Product Owner und dem Team eine Idee, wie viel Wert im nächsten Sprint erzeugt werden kann.

 

4. Abwesenheiten

Geplante Abwesenheiten, egal ob durch Urlaub, Feiertage (dann hat das ganze Team einen Tag weniger) oder Fortbildungen werden häufig beim Erstellen eines Commitments vergessen.

Einfach abfragen, eintragen und gemeinsam überlegen, welche Auswirkung die Abwesenheiten auf die Velocity haben.

 

5. Summe (initiales) Commitment

Interessant, um

  1. große Abweichungen zur Ø-Velocity festzustellen und ggf. festzuhalten, warum trotzdem diese Summe an Story Points (oder Stunden?) committed wird
  2. Auswirkungen von Scope-Änderungen im Sprint zu zeigen (Retrospektive!). Wenn aus versprochenen 30 Story Points des Teams am Ende des Sprint 43 werden (von denen 33 geschafft wurden), hat der Scrum Master ein Date mit dem Product Owner ;)

 

6. Summe der Bugs

Sicherlich auch ein Punkt, den nicht jeder hier erwarten würde, aber für mich ein Indikator, wie die Qualität des Produktes und die Verbesserung des Teams ist. Hier geht es mir nicht zuerst um die Gesamtsumme der Bugs. Für das gesamte Team ist es sinnvoll zu wissen, wie sich die Bug-Zahlen entwickeln. Also anhand der letzten zwei, drei Zahlen ableiten: "Arbeiten wir den Berg langsam ab" oder "Wir schaffen es nicht, die Bugs in den Griff zu bekommen".

 

7. Sonstige Notizen / Absprachen

Hier ist Platz für alles, was im Planning oder auch nebenbei festgehalten wird. Besondere Verantwortlichkeiten im Sprint, "geschützte" Zeiten, in denen das Team im Flow sein möchte und nicht von außen gestört werden will, ein dedizierter Ansprechpartner für einen Stakeholder usw.

Wir haben in einigen großen Projekten beispielsweise einen wechselnden Deploymentbeauftragten, der die Deployments steuert, Pull-Requests merged etc. Diese Rolle ist nicht optimal, aber zweckdienlich für einen bestimmten Zeitraum. Wer das ist, wird am Anfang des Sprints festgehalten.

 

8. Notizen während des Sprints

Das Tagebuch des Teams. Besondere Vorkommnisse , massive Scope-Änderungen, Impediments oder Ideen für die nächste Retrospektive/für weitere Experimente werden hier festgehalten. Alles, was von Bedeutung für das Team und die Velocity ist kann von jedem unzensiert festgehalten werden; ob das Thema Zeit bis zur Retro hat, kann das Team gemeinsam bestimmen. Die Notizen können dem Team vom Scrum Master im Vorfeld der Retro noch einmal per Mail oder "Merkzettel" zur Verfügung gestellt werden. Damit schafft ihr eine gute Grundlage für die Retrospektive und alle Beteiligten sind gedanklich wieder schnell in der "Geschichte des Sprints".

Hier könnt ihr das Canvas herunterladen:
 
Sprint_Canvas_v03.pdf 

Ich freue mich über Rückmeldungen, wenn ihr das Canvas ausprobiert habt! Inwiefern hat es geholfen, was könnte verbessert werden? Wenn ihr das Canvas weiterentwickelt, schickt mir gerne eure Version. Vielen Dank!

 

 

Short abstract for the English-speaking folks

The Sprint Canvas is a tool for teams / scrum masters to display relevant information of a sprint in a transparent way. It helps you to remember agreements from your last planning. You will gain a better forecast of what to achieve next on the basis of the average velocity of the last three sprints in combination with planned absences of team members for the next sprint.

It is also a tool to help you keep track of issues/impediments appearing during the sprint which can be relevant for the coming retrospective.

Free download of the Sprint Canvas here:

Sprint_Canvas_v03_EN.pdf 

Please share your thoughts and/or experiences with the Sprint Canvas! Thank you.