Wie lange sollte ein Agile Sprint dauern?

Wenn Scrum und Sprints für Sie neu sind, würde ich sagen, dass Sie mit einer bestimmten Länge (3 Wochen oder 30 Tage) beginnen und prüfen sollten, ob es für Sie funktioniert, und gegebenenfalls Änderungen vornehmen. Stattdessen sieht es so aus, als wären Sie bereits mit Sprints vertraut, also stellt sich die Frage: Wie sind Ihre Erfahrungen mit der Dauer von Sprints? Haben Sie irgendwelche Zweifel, die Sie dazu bringen, die Frage zu stellen?

Ich sehe ein paar Einflussfaktoren:

• Sprints sind mit einigen zusätzlichen Zeitkosten verbunden (Meetings, Planungen, Demo, auch ein freier Tag?). Ein zu kurzer Sprint bedeutet, dass das Arbeits-Kosten-Verhältnis niedrig ist.
• Sprints sollten liefern . Wenn Sie zu kurze Sprints wählen, werden einige von ihnen Schein-Sprints sein: Wenn das Sprint-Ziel nicht erreicht wird und fast nichts Interessantes auf der Demo zu zeigen ist, wird das Sprint-Ziel selbst ein Stub sein und Retrospektiven werden eher langweilig sein. Mit anderen Worten, Sprint wird nicht liefern.
• ...und liefern regelmäßig . Wenn Sie zu lange Sprints wählen, werden Sie wahrscheinlich feststellen: überfüllte Demo, zu viele Ziele pro Sprint und Rückblicke, bei denen sich niemand daran erinnert, was zu Beginn des Sprints passiert ist. Der Client wird mit Funktionen „überschwemmt“, sobald der Sprint vorbei ist, sodass Sprints nicht häufig (agil) genug sind.
• Es sollte keine Verzögerungen zwischen den Sprints geben . Machen Sie die Demo, Retrospektive, Rückstandsauswertungen, (freier Tag, wenn es eine solche Regel gibt) Planungstreffen und starten Sie den nächsten Sprint. Die 5. Woche solltest du dir genauer anschauen, da sie 20% deiner Zeit in Anspruch nimmt. Sie können wahrscheinlich Fehler in der Sprintzeit beseitigen, das Deployment vereinfachen und in Bezug auf POs: Sie sollten bereits Aufgaben für den nächsten Sprint vorbereitet haben, oder?

Ich kann Ihnen nicht die genaue Anzahl der Tage nennen, die ein Sprint dauern sollte, da das, was ich oben gesagt habe, eng mit der Teamqualität, der verwendeten Technologie und Architektur sowie dem Produkt, an dem Sie arbeiten, verbunden ist. Es ist wahrscheinlich nicht die beste Idee, die Sprintlänge zu oft zu ändern, da dies Ihre und die Fähigkeit des Teams, die Geschwindigkeit vorherzusagen, beeinträchtigt.

Je kürzer der Sprint – desto besser. Das ist die Faustregel. Es gibt jedoch viele Hindernisse, die es uns nicht erlauben, beispielsweise jede Woche zu liefern. Einige dieser Hindernisse sind:

• Projektsponsor/Kunde hat eine gewisse Bürokratie
• Ressourcen (Menschen) sind langsam in der Bereitstellung
• Einige Aufgaben dauern länger und können nicht in Unteraufgaben aufgeteilt werden

Dies sind die wichtigsten. Analysiere deine und versuche, mit ihnen zu kämpfen, um deine Sprints so kurz wie möglich zu halten. Im Allgemeinen erscheint Ihre Dauer von 4/5 Wochen für durchschnittliche Umstände angemessen. Aber noch einmal, ich würde empfehlen, zu versuchen, es kürzer zu machen.

Generell gilt, je kürzer der Sprint, desto besser auch beim Start. Je kürzer der Sprint, desto eher müssen Sie prüfen und sich anpassen. Kürzere Sprints fördern auch bessere agile Praktiken: Reduzierung der laufenden Arbeit, reduzierte Batchgröße und besserer Durchsatz. Längere Sprints können alte Wasserfallgewohnheiten fördern. In einem kürzlich durchgeführten Webinar, das wir vor 2.800 Personen durchgeführt haben, haben wir die Teilnehmer nach der häufigsten Sprintlänge befragt und etwas mehr als 50 % haben innerhalb von 2 Wochen geantwortet. Dies ist die Sprintlänge, die wir im Allgemeinen empfehlen, obwohl es reifere Teams gibt, die überhaupt keinen Sprint haben.

Aus meiner Erfahrung heraus fand ich es gut, zu Beginn 7-10-tägige Sprints zu haben und sie später auf 15-20 Tage zu erhöhen, wenn das Team die Norming-/Leistungsphasen erreicht.

amelwin,

Ich habe an einem Projekt mit drei Teams gearbeitet, bei dem wir für eine 15-monatige Anstrengung zweiwöchige Sprints verwendet haben – dies war (für uns) die optimale Länge.

Ich sage „am Ende“, weil wir in den ersten Monaten ganz bewusst an einigen Grundlagen herumgebastelt haben, und die Sprintlänge war eine davon. Längere Sprints (IIRC, 4 Wochen war die längste, die wir versucht haben) waren nicht effektiv. Wir hatten das Gefühl, dass Feedback zu lange dauerte (Retrospektiven), Geschichten weniger präzise waren und Probleme eher in die Länge gezogen wurden, als dass sie schnell erledigt wurden. Ich glaube nicht, dass dies eine Selbstverständlichkeit ist – die Teams eines anderen Projekts könnten dies besser handhaben – aber unsere Erfahrung war, dass kürzer besser ist.

Hier gibt es keine Regel. Die häufigste Sprintlänge beträgt 2 Wochen. Die überwiegende Mehrheit der Teams, ich würde sagen, mehr als 90 % derjenigen, die Timeboxing verwenden, hätten zwischen 1 und 4 Wochen Zeit.

Aber ich glaube nicht, dass es eine universelle Lösung gibt, die für alle passt.

Es gibt keine Regeln, wie viele Iterationen Sie im Projekt haben sollten oder wie sich die Anzahl der Personen im Team auf die Sprintlänge auswirkt. Man hört oft „je kürzer, desto besser“, aber es geht wirklich um Rückkopplungsschleifen. Fragen Sie sich, wie kurze oder lange Feedbackschleifen Sie benötigen. Wie oft planen Sie die Überprüfung Ihres Kurses? Da das Ende jeder Iteration eine natürliche Gelegenheit ist, eine solche Prüfung durchzuführen, kann dies ein guter Hinweis sein.

Wie auch immer, der wahrscheinlich beste Rat, wenn es um die Entscheidung über die Sprintlänge geht, ist: Experimentieren Sie.

Versuchen Sie es mit dem, was sich gut anfühlt, Sie können einen der Industriestandards wählen, wenn Sie keine bessere Idee haben, und dann schauen Sie, wie die Dinge laufen, passen Sie es an und bewerten Sie die Ergebnisse. Wenn du 14 Monate für das Projekt hast, hast du auch genug Zeit, um den richtigen Rhythmus für dich zu finden.

Schließlich hängt viel von den Menschen im Projektteam ab und das ist mit einfachen Methoden kaum zu evaluieren. Es ist besser zu prüfen, was funktioniert und was nicht, als umfangreiche Analysen zu diesem Thema anzustellen. Siehe Nathan Furrs Artikel über Planen versus Experimentieren als Referenz.

Laut ScrumMethodology.com dauert ein Sprint 30 Tage. Ich sehe jedoch Vor- und Nachteile darin, sowohl längere als auch kürzere Sprints zu haben. Tatsächlich beschreibt der Scrum Guide der Scrum.org-Website einen Sprint aus den folgenden Gründen als nicht länger als 30 Tage :

Sprints sind auf einen Kalendermonat begrenzt. Wenn der Horizont eines Sprints zu lang ist, kann sich die Definition dessen, was gebaut wird, ändern, die Komplexität kann steigen und das Risiko kann zunehmen. Sprints ermöglichen Vorhersagbarkeit, indem mindestens jeden Kalendermonat eine Überprüfung und Anpassung des Fortschritts in Richtung eines Sprint-Ziels sichergestellt wird. Sprints begrenzen außerdem das Risiko auf die Kosten eines Kalendermonats.

Je länger die Sprints werden, desto weniger agil sind Sie wirklich, insbesondere wenn Sie die Regeln der Scrum-Methodik befolgen, die es Ihnen nicht erlauben, den Sprint mittendrin zu unterbrechen oder zu ändern.

Je kleiner die Sprints, desto agiler wirst du; Es kann jedoch für das Entwicklungsteam schwieriger sein, mehr Arbeit zu erledigen, da das Produkt am Ende jedes Sprints in einer funktionierenden Version vorliegen muss.

Ich habe das Gefühl, dass die Komplexität der aktuellen Sprints sehr gut ihre Länge bestimmen könnte. Wenn Sie sich in der Phase des Projekts befinden, in der Sie nur kleinere Fehler beheben, sind kleinere Sprints möglicherweise einfacher. Wenn Sie jedoch größere Änderungen am System vornehmen, die viel Konzentration des Entwicklungsteams erfordern, sind möglicherweise längere Sprints angemessener.

Denken Sie schließlich daran, dass Sie, wenn die Sprints länger als 30 Tage dauern müssen, möglicherweise mit dem Entwicklungsteam nachfragen und es fragen müssen, ob sie das System unter Berücksichtigung agiler Best Practices entwerfen. Viele heute gängige Techniken, wie z. B. die Verwendung einer RESTful-Architektur, ermöglichen unabhängige Bereitstellungen modularer Komponenten, was dazu beiträgt, Fehler in anderen Systemen zu vermeiden und eine Umgebung zu schaffen, in der Bereitstellungen tatsächlich häufiger durchgeführt werden können.

Sie können eine gute Berichterstattung zu Ihrer spezifischen Frage sehen, aber wie arbeiten Sie 4/5 Wochen lang für Ihr Team, Ihren Kunden und Ihr System?

Hast du schon andere Längen probiert? Haben sie bessere Ergebnisse geliefert, war es einfacher zu planen, Mehrwert zu liefern, war das Team zufriedener?

Wie läuft Ihre allgemeine Implementierung von Agile? Hilft Ihnen die 4/5-Wochen-Zeitbox dabei, den anderen Teil des Agile/Scrum-Belegs für die Softwareentwicklung zu übernehmen?

Haben Sie aufgehört, sich zu verbessern? Wo hast du mit deiner Sprintlänge angefangen? Managen Sie und Ihr Team die Duration aktiv, wie es Ken Clyne gesagt hat ?

Basierend auf diesen Antworten würde ich sagen, dass Sie es selbst aktiv verwalten und die Faustregeln überspringen müssen.

In einem meiner Projekte, das 60 Wochen dauert ( ähnlich wie Ihres ), hat mein Team in einem 4-Wochen-Sprint gearbeitet und es lief gut.

Um Ihre Frage jedoch zu beantworten: Es gibt KEINE Faustregel für eine angemessene Anzahl von Sprints. Ich habe viele Projekte geleitet, derzeit 5 Projekte gleichzeitig. Einige von ihnen dauern weniger als 10 Sprints, andere 10-30 Sprints und einige besonders lange Projekte dauern > 50 Sprints. Und jedes Projekt kann eine andere Sprintlänge haben (1, 2 und 3 Wochen) .

In der Agile-Gruppe, an der ich teilnehme , wählen viele Teams einen Zeitraum von 30 Tagen, während viele Teams 2 Wochen und 3 Wochen wählen.

Wie bestimme ich also die Sprintlänge? Die Entscheidung wird getroffen, nachdem Folgendes berücksichtigt wurde: Geschätzte Projektdauer, Art des Produkts, Art Ihres Teams.

1) Geschätzte Projektdauer.

Die Schätzung muss nicht zu 100 % genau sein, um Ihnen ein Gefühl dafür zu geben, wie lange das Projekt dauern wird. Wenn es länger als 6 Monate dauert, ist es sinnvoll, eine 3-Wochen-Länge oder eine 30-Tage-Länge in Betracht zu ziehen.

2) Art des Produkts.

Sie müssen sich fragen:

• Muss dieses Produkt häufig an die Bedürfnisse des Marktes/der realen Benutzer angepasst werden, um einen Mehrwert für die Stakeholder zu schaffen? Wenn dies der Fall ist, sollten Sie die Sprintlänge verkürzen und häufiger eine funktionsfähige Version bereitstellen, um das Feedback der Öffentlichkeit zu erhalten.
• Ist es technisch möglich, das Produkt in kurzer Iteration zu liefern? Wie Sie wissen, wird eine kurze Iteration empfohlen, aber Sie können dies aufgrund technischer Schwierigkeiten nicht zu 100 % tun. In manchen Projekten müssen wir zum Beispiel einen komplexen Algorithmus implementieren, bevor wir ihn den Stakeholdern zeigen.

3) Art Ihres Teams

Arbeitet Ihr Team am effizientesten in 1-Wochen-Sprints oder in 30-Tage-Sprints? Wenn Sie mit dem Team an mehreren 2-wöchigen Sprints gearbeitet haben und das Gefühl haben, dass sie gut funktionieren, warum sollten Sie es nicht in Erwägung ziehen?

Sie könnten versucht sein, einen 1-wöchigen Sprint auszuprobieren, aber denken Sie daran, dass die eigentliche Arbeit des Programmierens aufgrund des (fast) gleichen Aufwands für Agile (Meetings, Kommunikation usw.) reduziert wird.

In meinen aktuellen Projekten wählen wir für Wartungsprojekte oft 1-wöchige Sprints und für andere arbeiten wir effizient in 3-wöchigen Sprints und 4-wöchigen Sprints, um persönliche Erfahrungen auszutauschen.

Ich denke, es hängt vom Projekt ab – ich habe das Projekt mit 1-Wochen-Sprints und 3-Monats-Sprints geleitet, also hängt es wirklich von den Zielen ab. Ich glaube auch, dass es am wichtigsten ist, sich realistische Ziele zu setzen.

Kürzere Sprints übertrumpfen im Allgemeinen längere Sprints.

Aus einem viel längeren Blogbeitrag Shorter Trumps Longer

Vorteile

• Da das Team mehr, aber kürzere Retrospektiven hat, hat es mehr Möglichkeiten, kleinere Änderungen auszuprobieren. Dies bietet auch mehr Möglichkeiten zum Lernen.
• Häufigere Sprint Reviews geben dem Product Owner mehr Feedback und häufigere Gelegenheiten zur Änderung. Dies sollte weitgehend die Notwendigkeit beseitigen, dass der Product Owner im aktuellen Sprint jemals nach einer Änderung (dh einer neuen Story) fragen muss.
• Hindernisse und Verlangsamungen werden schneller hervorgehoben, da vom Team erwartet wird, dass es die Funktion(en) bis zum Ende jedes Sprints erledigt. Dies zwingt das Team, sich mit Dingen abzufinden, die es verlangsamen.
• Kürzere Zyklen erleichtern die Planung, was den Fokus erhöht und die Menge an „Dunkelarbeit“ reduziert. Zwingt Teams, Storys oder Features besser in kleinere Stücke zu zerlegen. Dies erhöht die Sichtbarkeit und gibt dem Product Owner eine bessere Kontrolle über Priorisierung und Depriorisierung.

Nachteile

• Es ist schwieriger, am Ende eines ein- oder zweiwöchigen Zyklus zu einem fertigen Produkt zu gelangen. Das gilt zwar zunächst, aber die meisten Teams haben nach drei bis vier Sprints den Dreh raus.
• Das Arbeiten in einwöchigen Sprints kann anfangs stressiger sein.
• Overhead – Die Leute sagen, dass die Sprint Meetings zu viel Overhead für einen einwöchigen Sprint sind. Sprint-Meetings skalieren jedoch linear mit der Länge eines Sprints. Ein einwöchiger Sprint hat also 2 Stunden Sprintplanung, ein zweiwöchiger Sprint hat 4 Stunden und so weiter.

Heute wählen die meisten Teams, denen ich begegne, zweiwöchige Sprints. Manche gehen nur eine Woche.

Ich denke, ein guter Sprint sollte ungefähr 4 Wochen dauern. also im Grunde gleich einer Iteration. Eine Iteration muss nicht unbedingt eine produktionsreife Version sein, sollte aber zumindest eine interne Version zum Testen sein. Jeder Sprint sollte darauf abzielen, mehrere User Stories zum Testen fertigzustellen

Die Entwickler im Team sollten entscheiden, was für sie am besten funktioniert. Es kann sein, dass kurze Sprints am Anfang am besten funktionieren, dann längere Sprints in der Mitte, dann kürzere Sprints am Ende. Oder umgekehrt. Oder alle gleich groß, nach 4 Wochen. Oder vielleicht erweisen sich 4 Wochen als zu lang für den empirischen Ansatz von Scrum, sodass das Entwicklerteam möglicherweise beschließt, es auf 3 Wochen zu reduzieren.

Zum Glück für den PM ist die Länge des Sprints nicht seine Angelegenheit. Angenommen, der PM ist der Product Owner und kein Mitglied des Entwicklerteams.

Amelwin,

Ein paar Gedanken zu dem, was Sie mit uns geteilt haben. Ich verstehe, dass Sie das Framework an die spezifischen Gegebenheiten Ihres Unternehmens anpassen müssen, aber hier sind ein paar Dinge, von denen ich persönlich abraten würde.

Warum die 5. Woche Pause? Eines der Ziele von Scrum ist es, ein nachhaltiges Tempo beizubehalten. Wenn Sie alle 4 Wochen eine Pause brauchen, deutet das darauf hin, dass Sie das Team der anderen 4 Wochen überlasten. Werden Sie in der Lage sein, das 14 Monate lang durchzuhalten?

Bereitstellungsaufgaben sollten im Sprint enthalten sein. oder noch besser, zielen Sie so weit wie möglich auf die Bereitstellungsautomatisierung ab. sie sollten auch nicht die Ausrede für die arbeitsfreie Woche sein.

Die Notwendigkeit von Fehlerbehebungen wirft die Frage nach der Qualitätskontrolle auf. Wie stellen Sie die Qualität Ihrer Sprints sicher? Wie hat sich Ihre Definition von Done entwickelt? Eine Fehlerbehebungswoche führt dazu, dass das Entwicklungsteam Abstriche macht und die Qualität reduziert. Es nährt den Gedankengang, dass Probleme „während der Bugfix-Woche damit behoben werden können“. Und bevor Sie es wissen, kommen Dinge, von denen Sie dachten, dass sie erledigt sind, immer wieder zurück, um eine Lösung nach der anderen zu beheben. Ein gesundes DoD ist entscheidend für Transparenz und Transparenz ist der Schlüssel zum Projekterfolg. Mein Rat ist, streng mit Ihrer Definition von „fertig“ zu sein und das Team dazu zu bringen, es bei jeder Retrospektive wachsen zu lassen. Nicht-funktionale Anforderungen sind großartige Kandidaten für Definition-of-Done-Prüfpunkte.

Die letzte Aktivität, die Sie anscheinend in Ihre freie Woche packen, ist das Schätzen und PB-Grooming. Sie müssen nicht den gesamten Rückstand geschätzt und priorisiert haben, aber Sie sollten Stories im Wert von 2 bis 3 Sprints jederzeit einsatzbereit haben. Dazu sollte der Product Owner regelmäßig die Prioritäten überprüfen und das Team muss während des Sprints Zeit für eine Poker-Planungssitzung oder einen anderen von Ihnen verwendeten Schätzansatz einplanen.

Lesen Sie sich den Scrum-Leitfaden von scrum.org durch, und ich würde vorschlagen, dass das gesamte Team eine formelle Scrum-Schulung von entweder .org oder der Alliance durchläuft. Die meisten Entscheidungen müssen im Team getroffen werden. Die Dauer des EG-Sprints sollte vom Scrum-Team festgelegt werden. Es ist immer besser, wenn jeder die grundlegende Anleitung und die Begründung dahinter versteht.

Viel Glück für Ihr Projekt

Ich bin eher auf der Entwicklungsseite und wollte mich hier nur einklinken.

Ein häufiger Fehler, den ich bei PMs sehe, ist der Versuch, Arbeitsblöcke in einen regelmäßigen Zeitplan einzubinden, anstatt den Arbeitsblock zu planen.

Stellen Sie sich zum Beispiel eine Situation mit 6 gehobelten Blöcken vor:

• Merkmal A (1w 3d)
• Verbesserung B (4d)
• Merkmal C (1w 1d)
• Genehmigte Fehlerbehebungen (3d)
• Refactoring 5 (2w 4d)
• Verbesserungen der Fehlerbehandlung (2d)

Der Versuch, diese in zweiwöchige Sprints aufzuteilen, zwingt dazu, sie so zu ordnen, dass mehr Arbeit für Ihr Entwicklerteam entsteht, und einige Blöcke werden in mehrere Sprints aufgeteilt. Genau das soll Agile vermeiden.

Erwägen Sie stattdessen, die Blöcke zu planen, die erledigt werden müssen, wie viel Zeit jeder benötigt und in welcher logischen Reihenfolge sie geliefert werden sollten. Machen Sie dann aus jedem Block einen eigenen Sprint und planen Sie ihn. Lassen Sie es einen 2-Tages-Sprint für die Fehlerbehandlung geben. Lassen Sie es einen 3-wöchigen Sprint für das Refactoring geben. Projektmanagement und Terminplanung sollten das Projekt verwalten, nicht vorantreiben.

Dies ist ein Kompromiss. Wenn die Sprintdauer extrem kurz ist, gibt es höhere Overheads wie z. B. Anzahl Retrospektiven, Demos usw. Die Transaktionskosten sind also hoch. Wenn die Sprint-Dauer zu lang ist, dauert es länger, bis die fertigen Funktionen in die Hände der Kunden gelangen, was zu verzögerten Einnahmen führt. dh höhere Haltekosten. Ihre optimale Sprint-Dauer ist, wenn sich Ihre Transaktions- und Haltekosten treffen.