Scrum
Story Points: Wieso, weshalb, warum und vor allem wie?
Was sind Story Points, warum gibt es sie überhaupt und wie kann man sie denn nun schätzen? All das erfahren Sie hier. Sie werden überrascht sein, was alles in ihnen steckt!
Was ist die optimale Scrum Sprint Länge? Die überraschende Erkenntnis: 1-wöchige Sprints sind effektiver! Lese hier warum.
Scrum organisiert die Wertschöpfung in Iterationen, sogenannten Sprints. Sprints sind in Scrum zunächst einmal nichts anderes als Timeboxen, also einfach nur eine Zeiteinheit. Nicht mehr, aber auch nicht weniger.
Damit – und das ist der interessante Aspekt an Scrum – führt Scrum ein anderes Paradigma des Zeitmanagements ein.
Auch Wasserfall kennt bestimmte Phasen wie Spezifikationsphase, Implementierungsphase, Testphase, Dokumentationsphase, Abnahmephase, etc. Hier aber sind die Zeitabschnitte an bestimmten Content gebunden und der Content bestimmt letztlich die Länge des Zeitabschnittes. Die Phase ist beendet, wenn die Ziele dieser Phase erreicht sind bzw. zumindest zufriedenstellende Ergebnisse geliefert hat.
Scrum dreht das Verhältnis zwischen Timebox und Content genau um. Die Timebox, also die Länge des Sprints ist klar definiert und sollte sich möglichst selten ändern. Dazu kommen wir gleich noch
Variabel ist der Content, genauer der Scope, der in dieser Timebox geliefert werden soll.
Auf dem ersten Blick scheint dieser Paradigmenwechsel erforderlich zu werden wegen vertikaler (end-2-end) und featureorientierter Entwicklung, die Scrum einführt. Aber das Entkoppeln von Timebox und Scope eröffnet Scrum-Teams noch mehr Möglichkeiten.
Das Entkoppeln von Timebox und Scope eröffnet eine wesentlich größere Flexibilität. Bei der Wahl der Länge eines Sprints kann plötzlich auf andere Dinge Rücksicht genommen werden, als nur auf den Scope.
Die Sprintlänge wird damit mehr zu einem strategischen Instrument um den Flow von Value besser zu unterstützen. Folgendes Beispiel verdeutlicht das:
Neben Bugs sind ständige Scope-Changes mitten im Sprint nicht nur ein Ärgernis von Scrum Teams, sondern sie sind vor allem sehr teuer und ein absoluter Velocity-Killer.
Crossfunktionale Teams haben sich während des Plannings, dass ja mit allen Aktivitäten zusammengenommen, mehrere Tage Aufwand (nicht Dauer) über alle Teammitglieder hinweg kostet, viel Mühe gegeben, einen Scrum Sprint perfekt auszubalancieren.
Ein Scope-Change zerstört sofort diese Balance, ein Replanning ist notwendig und all das kostet.
Teams, die sich ständig Scope-Changes gegenübersehen, könnten die Länge der Sprints z.B. auf eine Woche verkürzen, gegebenenfalls auch nur für eine Phase
In der Zwischenzeit kann der Scrum Master gemeinsam mit Stakeholdern die Ursachen für permanenten Scope Change bearbeiten, was auch immer diese sein mögen.
Das Konstrukt Sprint wird hier als strategisches Instrument verwendet und ist nicht nur Träger des Scopes.
Wenn Sie mich fragen, ist die optimale Länge eines Sprints nicht zwei Wochen, sondern nur eine Woche.
Nicht nur, weil die Gefahr von teuren Scope-Changes hier am geringsten ist, sondern aus einer Reihe von weiteren Gründen:
Scrum ist eine schwierige Angelegenheit keine Frage. Wir sollten also alle Hilfen nutzen, um uns die Sache nicht noch schwieriger zu machen, sondern einfacher. Wir kennen den Wochenrhytmus quasi seit unserer Geburt und daher fällt es uns auch relativ leicht, den Zeitraum von einer Woche ziemlich präzise zu planen.
Je kürzer der Sprint ist, desto kleiner müssen auch die Storys sein. Ich habe viele Teams gesehen, die völlig genervt sind, von Product Ownern, die es lieben Mammut-Stories zu schreiben. Extremfälle von zwei Storys für einen dreiwöchigen Sprint mit einem siebenköpfigen Team, alles schon gesehen. Kurze Sprints zwingen die PO‘s kleine Storys zu schreiben.
Ich habe zudem oft Teams gesehen, die in der ersten Woche des zweiwöchigen Sprints die Sache ziemlich relaxed angehen, nach dem Motto „wir müssen ja erst nächste Woche liefern“.
Die Vorliebe für längere, mindestens zweiwöchige Sprints beruht meist auf der irrigen Annahme, dass in längeren Sprints weniger Zeit für Meetings (Planning, Review, Retrospektive) verlorengeht und mehr netto Wertschöpfungszeit übrig bleibt.
Meine Erfahrung sagt eher das Gegenteil.
Lange Sprints zu planen dauert länger und ist deutlich ermüdender.
Scrum.org sagt, ein Planning für einen vierwöchigen Sprint darf bis zu 8 Stunden dauern. Mal im Ernst, wer möchte 8 Stunden in einem intensiven fachlich/technischen Workshop sitzen, bzw. wer erwartet ernsthaft, dass da etwas Sinnvolles bei rauskommt?
In kurzen Sprints sind die Meetings zwar häufiger, dafür aber sehr viel kürzer.
Eine Retrospektive kann man z.B. trotzdem alle zwei Wochen machen. So viel gibt es eh nicht jede Woche zu verbessern, bzw. um signifikante Dinge zu verbessern braucht es oft mehr Zeit.
Aber genau das ist es, was Teams oft nicht so gerne mögen. Ich habe oft gesehen, dass Dev-Teams und PO‘s ganz gerne auf Distanz bleiben und nicht das allerbeste Verhältnis pflegen. Bei kurzen Sprints müssen sie öfter und direkter miteinander kommunizieren.
Die Mission ist, aus einem 5 tägigen Sprint, 4,5 Tage netto Entwicklungszeit herauszukitzeln. Und das geht.
Tatsache ist, dass kürzere Sprints noch mehr Transparenz schaffen und noch mehr Disziplin einfordern. Anders kommt man eben nicht zu 4,5 Tagen Netto Wertschöpfungszeit.
Auch der Scrum Master muss intensiver mit dem Team arbeiten, um den Takt kurz zu halten.
Was sind Story Points, warum gibt es sie überhaupt und wie kann man sie denn nun schätzen? All das erfahren Sie hier. Sie werden überrascht sein, was alles in ihnen steckt!
Was ist der Unterschied zwischen einer vertikalen und horizontalen Organisation und wie bildet man eine vertikale Organisationsstruktur? Roadmap für agile Transformation + Case Study
Inhalt Seitdem der Begriff ‚agiles Projektmanagement‘ aufgetaucht ist, gibt es eine fortwährende Diskussion über das Verhältnis von etablierten Projektmanagement Methoden (PMM) wie zum Beispiel PRINCE 2 oder PMI zu
Für Scaled Agile Organisationen kann es frustriererend sein, wenn Projektmanagement Tools ihre Prozesse nicht unterstützen.
Daher haben wir scagile als eine App entwickelt, die aktiv agile Best-Practices fördert und mit der ein Value Flow über die gesamte Organisation hinweg etabliert wird.
