Heute dreht sich alles Rund um das Thema Scrum Sprint. Dabei stellen wir dir dieses Event genauer vor und erklären dir die time-box, was das Ergebnis jedes Sprints sein sollte und was es während des Sprints zu beachten gibt.
In der letzten Folge haben wir dir das Scrum Framework vorgestellt inklusive einer Übersicht über alle 3 Rollen, 5 Events, 3 Artefakte und 5 Werte. Wenn du also darüber mehr wissen willst schau gerne hier vorbei.
Wie alle Events ist auch der Sprint zeitlich begrenzt, also time-boxed, auf maximal 4 Wochen. Dabei legt das Scrum Team selbst fest, wie lange der Sprint gehen soll. Die Dauer des Sprints sollte sich dabei aber nicht während eines Entwicklungsprozesses ändern. In der Regel ist ein Sprint der kürzer als eine Woche ist kaum möglich, da dies dem Entwicklerteam zu wenig Zeit lässt, um ein fertiges Produkt zu entwickeln.
Grund für dieses time-boxing des Sprints ist, dass dadurch das Risiko minimiert wird, dass zu lange etwas falsches entwickelt wird. Man reduziert also absichtlich die maximale Zeit die man vom Kunde und dessen wertvollem Feedback getrennt ist. Dadurch wird auch automatisch die Unsicherheit minimiert, da man nicht versucht 6 Monate oder noch länger im voraus zu planen. Der Product Owner sollte diese Trennung vom Kunde und die Unsicherheit die dadurch entsteht immer im Hinterkopf haben.
Das Ziel eines jeden Sprints ist es, dass am Ende ein fertiges potenziell auslieferbares Inkrement entsteht. Grund hierfür ist, dass man nur wenn das erfüllt ist auch konstruktives Feedback vom Kunden bzw. den Usern einholen kann. Ein neuer Sprint beginnt immer unmittelbar nach dem Ende des vorherigen Sprints, also nach der Sprint Retrospektive.
Während des Sprints gilt es bestimmte Dinge zu beachten, damit das das Ziel des Sprints erreicht werden kann. Und genau das ist bereits ein Teil dessen, was es zu beachten gilt. Es darf nichts gemacht werden, was die Erreichung des Sprint Goals gefährdet oder gar verhindert.
Was sich aber ändern kann ist der Umfang, der während des Sprints vom Entwicklerteam bearbeitet wird. So kann das Team, sollte es besser vorankommen als geplant, auch noch weitere Elemente aus dem Product Backlog bearbeiten. Dies kann z.B. auch passieren wenn das Team neue Erkenntnisse hat und dadurch eventuell bestimmte Aufgaben überflüssig werden. Diese dürfen dann auch aus dem Sprint gestrichen werden. Wichtig ist hierbei allerdings, dass das nur im Einvernehmen mit dem Product Owner geht.
Ein weiteres essenzielles Kriterium ist, dass die Qualität des entwickelten Inkrements während des Sprints niemals sinkt. Das heißt vor allem, dass die Definition of Done nicht abgeschwächt wird. Sie kann aber vom Team erweitert werden, wenn dieses feststellt, dass ein weiteres Kriterium in die Definition of Done aufgenommen werden sollte.
Die einzige Person, die den Sprint beenden kann ist der Product Owner. Dies passiert sehr selten und sollte auch nur im äußersten Notfall geschehen. Der Abbruch des Sprints ist für das ganze Team in der Regel eine sehr negative und demotivierende Erfahrung, darum sollte dies so gut es geht vermieden werden. Beim Abbruch eines Sprints müssen auch immer die (zeitlichen) Kosten für das reorganisieren der Teams etc. bedacht werden, da diese in der Regel nicht unerheblich sind. Aufgaben die bis zum Abbruch des Sprints bereits fertiggestellt wurden, werden in der Regel vom Product Owner akzeptiert. Die übrigen Aufgaben wandern zurück in den Product Backlog und werden neu priorisiert. Wichtig zu beachten ist, dass der Product Backlog solange existiert solange auch das entsprechende Produkt existiert.
Der Fortschritt des Teams während des Sprints kann z.B. mittels eines Burndown– oder Burn-Up-Charts analysiert werden. Dabei gilt es vor allem aus dessen Entwicklung Rückschlüsse auf eventuelle Impediments des Teams oder ähnliches zu ziehen und diese dann mit dem Team zu besprechen. Es geht nicht darum, dass das Team unbedingt alles erfüllen muss, was es vorhergesagt hat.
Eine weitere Metrik, die wichtig ist für den Sprint ist die Velocity des Teams. Sie besagt, wie viele z.B. Storypoints das Team pro Sprint abarbeiten kann. In der Regel. Diese Metrik sollte auf keinen Fall dafür benutzt werden, um Teams zu vergleichen und dadurch Druck auf die Teams auszuüben. Vor allem nicht, da diese Metrik auch gar nicht dafür geeignet ist, da sie keinerlei Aussage über den Mehrwert für den Kunden zulässt, was das klare Ziel von jedem Sprint ist.
Beim Aufbau des Sprints lässt sich ein sehr enger Zusammenhang zum Lean-Startup Modell und dessen Minimum Viable Product (MVP), also dem minimal funktionsfähigen Produkt, erkennen.
Wie du siehst gibt es auch während des Sprints viele Dinge zu beachten, die die Performance des Teams positiv beziehungsweise negativ beeinflussen kann. Wichtigstes Ziel ist es mit Hilfe eines auslieferbaren Inkrements Feedback vom Kunden zu bekommen und das möglichst oft, um das Risiko zu minimieren. Nun interessiert uns aber wie immer auch deine Erfahrung zum Thema Sprint in Scrum.
Fragen an dich:
Schreib es uns in den Kommentaren.
Da das jetzt alles sehr viel auf einmal war, haben wir eine einfache Übersicht über alles was zu diesem Scrum Rahmenwerk gehört, für euch in einem kostenlosen Poster dargestellt. Du findest es hier:
In der nächsten Folge stellen wir dir die 3 Rollen von Scrum genauer vor. Also was genau sind die Aufgaben im Scrum Framework und welche Verantwortung hat der Scrum Master, Product Owner und das Entwickler Team. Falls du das nicht verpassen wollt, melde dich einfach für unseren kostenlosen Newsletter an:
Und falls du unsere Experteninterviews und alle anderen Podcast Folgen als erster hören willst, abonnier einfach unseren Podcast auf:
Du stehst auf bewegtes Bild? Dann ab auf unseren YouTube-Channel “Agile Coach Academy”.
Abonniere den Channel und verpasse kein Video oder Experteninterview mehr.
Wie immer freuen wir uns auch wenn du diesen Artikel mit deinen Freunden, Kollegen und Bekannten teilst und uns dein ehrliches Feedback in den Kommentaren schickst.
Wir freuen uns auf dich.
Deine Agile Coach Academy Gründer Ben und Alex
