Scrum: Kurzer VS langer Sprint

8

Wir haben versucht, die optimale Sprintlänge für unser Projekt herauszufinden. Nachdem wir 3 Wochen gearbeitet hatten, dachten wir, dass eine Verkürzung des Sprints auf 2 Wochen eine bessere Geschwindigkeit bringen würde.

Die Vorteile waren klar: kürzere Rückkopplungsschleife, kleine Geschichten (mit Benutzerwert) und so weiter. Auf der anderen Seite gibt es viele Nachteile wie Zeremonien (Planung, Rückblick) usw., bei denen wir nicht produzieren und jetzt häufiger auftreten.

Ich habe mich gefragt, wie wir für ein neues Team die optimale Sprintlänge bestimmen können.

— Avi
quelle

1

Während Planung und Rückblick häufiger vorkommen, haben Sie nicht auch 2/3 so viel zu erzählen? Und können Sie das Meeting nicht verkürzen?

— pdr

3

Meine Erfahrung mit Scrum zeigt, dass die Retrospektive so lange wie möglich dauern wird. Die Planung mag etwas kürzer sein, aber ich bin mir nicht sicher, ob das genug ist. Außerdem gibt es die Demo zum Kunden- / Po- und Sprint-Review-Meeting.

— Avi

2

Das lässt zwei Möglichkeiten. 1. Ihre Retrospektive war, ist vielleicht noch zu kurz. Betrachten Sie das nicht als unproduktive Zeit, da dies Ihre Produktivität für den Rest der Zeit steigert. 2. Ihre Retrospektive ist nicht strukturiert und erreicht nicht viel. In diesem Fall liegt die Lösung auf der Hand.

— pdr

1

Über 1 - Ich stimme nicht zu, dass es kurz war. Die Leute in meinem Team lieben es einfach zu reden :) Wir versuchen, konzentriert zu bleiben, aber oft kommt es vor, dass die Diskussion an einen Ort geht, an dem nichts Produktives entsteht. Die zeitliche Festlegung der Retrospektive hilft dabei, solche Diskussionen zu unterbrechen und zu einer produktiven Diskussion mit klaren Schlussfolgerungen und Aktionspunkten für die Zukunft zurückzukehren. In Bezug auf 2 - Ich stimme zu und habe in letzter Zeit nach Möglichkeiten gesucht, unsere Rückblicke zu verbessern. Mabye, ich werde eine andere Frage für die Retrospektive öffnen.

— Avi

1

@pdr: Für jedes Meeting fallen feste Kosten an (z. B. vor und nach einer Unterbrechung werden Sie an nichts Ernsthaftem arbeiten). Daher können weniger Besprechungen effizienter sein als viele kurze Besprechungen.

— Giorgio

8

Ich denke, Sie sehen es etwas rückwärts. Geschwindigkeit ist ein Nacheffekt der Arbeit, die Ihr Team leistet. Es ist kein kausaler Faktor - dh. Es ist etwas, das Sie messen und das Sie nicht direkt optimieren können.

Diese Erklärung der Geschwindigkeit hat einen relevanten Aspekt für Ihre Frage.

Der einfachste Weg, die Geschwindigkeit zu definieren, ist: Die Anzahl oder User Stories, die ein Team / Projekt in einem Sprint ausführen kann

Und nach dieser Definition bedeutet ein längerer Sprint mehr Zeit für die Entwicklung pro Sprint und damit eine größere Geschwindigkeitszahl.

Die Relativgeschwindigkeit zwischen einem 2-wöchigen oder einem 3-wöchigen Sprint ist eine etwas andere Frage. Der Aufwand für Projektzeremonien kann sich darauf auswirken, wie viel Sie erledigen können, da insgesamt weniger Zeit zur Verfügung steht. Betrachten Sie diese Berechnung als eine Möglichkeit, verfügbare Entwicklungsstunden in einem Sprint zu identifizieren.

DevHoursAvailable = ((HoursInDay * DaysInSprint) - CeremonyOverhead) * AvailabilityFactor * NumberOfDevs

CeremonyOverheadist in der Regel festgelegt. Verringern Sie Ihre DaysInSprintund Sie können sehen, dass Sie während dieses Sprints weniger Zeit für die Entwicklung haben. Anhand eines einfachen Beispiels für 1 Entwickler sind hier die Zahlen für einige Sprintlängen aufgeführt.

1 Woche:
((8 * 5) - 4) * .8 = 28,8 Stunden oder 5,76 Stunden pro Tag.
2 Wochen:
((8 * 10) - 4) * .8 = 60,8 Stunden oder 6,08 Stunden pro Tag.
3 Wochen:
((8 * 15) - 4) * .8 = 92,8 Stunden oder 6,18 Stunden pro Tag.

Die "offensichtliche" Antwort ist, dass längere Sprints besser sind. Das Problem mit der offensichtlichen Antwort ist, dass die vorteilhaften Auswirkungen von Rückkopplungsschleifen ignoriert werden. Temperieren Sie Gedanken zu dieser Berechnung mit einer Gesamtperspektive darüber, was Agile in den Entwicklungsprozess einbringen soll.

Ich vermute, Ihr Kernproblem ist, dass Ihre User Stories nicht so definiert sind, wie sie sein könnten. Dieses Unverständnis darüber, was erforderlich ist, ist das eigentliche Hindernis für die Erledigung der Arbeit.

1

Das ist überhaupt nicht das Problem. Ich versuche wirklich objektiv zu überlegen, wie man eine solche Entscheidung trifft.

— Avi

2

@Avi - Abgesehen von meinen Spekulationen können Sie jetzt die quantitativen Auswirkungen verschiedener Sprintlängen betrachten. Geben Sie einfach die entsprechenden Zahlen für Ihr Team in Bezug auf Overhead und Ihren Auslastungsfaktor ein. Von dort aus haben Sie einen Spagat zwischen der Länge des Sprints und dem Einfluss auf den Rückkopplungszyklus. Im Übrigen empfiehlt Agile, die Dinge anders zu machen, um konstruktiv zu experimentieren und Verbesserungsmöglichkeiten zu identifizieren. Ändern Sie Ihre Sprintlängen für eine Weile und sehen Sie, was die Ergebnisse sind.

3

Sie sagten: "CeremonyOverhead ist im Allgemeinen behoben." Sollten Ihre Sprint-Rituale nicht mit der Größe Ihrer Sprints skalieren? In diesem Artikel wird behauptet, dass "Sprint-Meetings linear mit der Länge eines Sprints skaliert werden. Ein einwöchiger Sprint hat also 2 Stunden Sprint-Planung, ein zweiwöchiger Sprint 4 Stunden und so weiter." Das mag ein bisschen optimistisch sein, sollte aber nahezu linear sein.

— Sgryzko

7

Auf der anderen Seite gibt es viele Nachteile wie Zeremonien (Planung, Rückblick) und so weiter

Dies ist eine große rote Fahne. Wenn Sie es eher als Zeremonie denn als wesentliches Mittel betrachten, das dem Arbeitsprozess und seiner Verbesserung dient, hat die Arbeit daran wahrscheinlich mehr Gewinn als das Fummeln mit der Sprintlänge.

Der Prozess liegt in Ihren Händen (dh im Team). Sie sollten die am besten aussehenden Ideen verfolgen, wenn Sie experimentieren und sich anpassen müssen. Wir machten 2 Wochen und wechselten schließlich zu 3 Wochen und es funktionierte besser. Aber manchmal legen Sie einfach die Länge basierend auf der Schätzung für den Umfang fest. Ja, ich bin mir der Idee der "gleichen Länge" bewusst, aber es ist kein Dogma und passt möglicherweise nicht wirklich zu einem realen Projekt. Und ein klares und offensichtliches Sprintziel kann besser sein.

Die richtige Länge lässt sich wirklich nicht von außen ableiten. Sie sind da, um die relevanten Faktoren zu kennen. Bei der Planung können Sie mit "ok, was können wir in den nächsten X Wochen tun" beginnen. Oder stattdessen "was wäre das nächste sinnvolle Inkrement". In jedem Fall ist die Planung des letzteren gut, dann schauen Sie, wie lange es dauern würde. Und portionieren Sie das in einem oder mehreren Sprints.

— Balog Pal
quelle

1

Ich stimme Ihrer Diagnose zu. Die Besprechungen werden von einem erfahrenen Team kurz, einfach und effektiv gehalten. Lange Besprechungen, die das Team zu vermeiden versucht, sind ein sicheres Zeichen für eine fehlerhafte Implementierung von Agile.

— Sklivvz

2

Wie du willst. Probieren Sie beide aus und sehen Sie, was funktioniert. Verwende das.

Der beste agile Sprint, den ich je benutzt habe, war 6 Wochen. Wir haben so viel getan - aber wir mussten nur nach diesem Zeitplan an den Kunden liefern. Wir haben keine Aufgaben verwendet und das Arbeiten dem User-Story-Arbeitsstil vorgezogen.

— gbjbaanb
quelle

Ich weiß, es liegt an mir und jedes Team hat seine Vorlieben. Dennoch wollte ich einige Dinge sammeln, um bereits zu Beginn eine gute Entscheidung zu treffen. Übrigens. In diesem 6-wöchigen Sprint-Projekt hatten Sie mehr als einen Sprint?

— Avi

6 Wochen scheinen viel für einen Sprint zu sein, vielleicht zu viel. Ich denke, dass in den meisten Situationen, wenn Sie mit einem Sprint über 4 Wochen hinausgehen, Sie es wahrscheinlich falsch machen ...

— Radu Murzea

Ich denke, dass gbjbaanb nur 6 Wochen für das Projekt hatte. Oder mit anderen Worten - das Projekt war nur 1 Sprint. Natürlich kann auch ein 6-wöchiges Projekt in Sprints von 1-2-3 Wochen unterteilt werden.

— Avi

Wir hatten ungefähr 6-8 Monate Arbeit zu erledigen. Es ist einfach so passiert, dass 6 Wochen gut für uns und den Kunden waren, der unsere Lieferungen überprüft hat, und das ist der Punkt - ignorieren Sie jeden, der sagt, was ein Sprint sein sollte. Das macht Sie am produktivsten. Denken Sie daran, Agile sagt, liefern Sie regelmäßig funktionierende Software, es heißt nicht 2 Wochen. Ich habe an zweiwöchigen Sprints gearbeitet, bei denen wir viel recherchieren mussten, um die Lieferung zu machen. An jedem Ende waren die Demos in ihrer Kürze peinlich und das Feedback von ihnen war belanglos. Wir hatten also viel Overhead für wenig Ergebnis. YMMV

— gbjbaanb

1

Es kommt darauf an, was Sie als "neues Team" bezeichnen.

In der Tat hängt die Geschwindigkeit eines Teams von vielen Parametern ab (z. B. Junioren?, Senioren?, Neulinge?, Spannungen zwischen Teammitgliedern? Usw.).

Daher ist auch die "ideale" Sprintlänge an diese Parameter gebunden.

Auf jeden Fall gibt es dafür keine sofort einsatzbereite Lösung. Die einzige Möglichkeit besteht darin, sie mit dem Team selbst zu testen und auch die beste durchschnittliche Passform für alle Teammitglieder zu berücksichtigen.

— Vincent
quelle

1

Ich bezweifle Ihren Vorschlag einer "kürzeren Rückkopplungsschleife". Ihr Team sollte täglich mit Ihren Kunden zusammenarbeiten - das Feedback sollte nicht auf den Sprint Review und die Retrospektive warten. Testen, codieren, entwerfen und erhalten Sie sofort Feedback .

Ich persönlich mag den dreiwöchigen Sprint, weil die mittlere Woche dem Team etwas "Flow" -Zeit lässt. Das heißt, es gibt immer so viel Zeit, um die erste Woche zu drehen (zu lernen, was zum Teufel diese neuen Geschichten bedeuten) und einige, um die letzte zu beenden (Vorbereitung für die Rezension). Eine mittlere Woche, um einfach funktionierende Software zu produzieren, ist eine wirklich schöne Sache.

Wenn man diese Logik weiter verfolgt, wären vierwöchige Sprints noch sinnvoller. Das Gefühl der Dringlichkeit kann jedoch verloren gehen, wenn Sie Ihre Sprints verlängern. Darüber hinaus gibt es wirklich einen relativ kleinen Informationsblock, den eine Person oder ein Team gleichzeitig erfassen und in ihren bewussten Gedanken festhalten kann - je länger der Sprint, desto mehr Dinge, auf die Sie sich konzentrieren möchten, was die Dinge eher schwieriger machen kann als einfacher. Es ist auch schwieriger zu beurteilen, welche externen Faktoren sich einschleichen, wenn Sie die Dinge zu weit ausdehnen.

— Matthew Flynn
quelle

1

Da Sie nach einem neuen Team gefragt haben , wollte ich einige Gedanken hinzufügen. Ich arbeite seit über 15 Jahren mit Scrum und anderen agilen Methoden und empfehle jetzt immer , dass neue Teams mit einwöchigen Sprints beginnen. Dafür gibt es drei kritische Gründe:

Kürzere Sprints helfen Teams, schneller zu einem Hochleistungszustand zu gelangen. Lange Sprints bedeuten normalerweise, dass es 18 Monate bis zwei Jahre dauert, bis dieser Zustand erreicht ist. Kurze einwöchige Sprints helfen einem Team, in nur zwei oder drei Monaten diesen Hochleistungszustand zu erreichen. Natürlich müssen auch andere Dinge vorhanden sein, um eine hohe Leistung zu erzielen (siehe "Die Weisheit der Teams" von Katzenbach und Smith).
Wie andere bereits erwähnt haben, erhöht ein kürzerer Sprint den Rückkopplungszyklus. Ein einwöchiger Sprint scheint für die meisten Teams, die Software- oder Produktentwicklung betreiben, optimal zu sein. Das Feedback sollte hauptsächlich während der Sprint-Überprüfung erfolgen, die an die Stelle Ihres traditionellen UAT-Prozesses treten sollte.
Schließlich üben kürzere Sprints Druck auf Ihr Team aus, um organisatorische Hindernisse für eine häufige Lieferung zu überwinden. Dieser Druck ist zunächst sehr unangenehm, aber wesentlich für die Verbesserung Ihrer gesamten Entwicklungsprozesse, einschließlich Planung, Compliance, Releases usw.

Ich habe einen Artikel mit dem Titel 21 Tipps zur Auswahl einer Sprintlänge geschrieben , der von Interesse sein könnte.

— Mishkin Berteig - Agiler Coach
quelle

0

Die Zeremonien haben einen Zweck - wenn wir den Zweck erkennen, erkennen wir, dass sie kein Aufwand, sondern ein Mehrwert sind.

Planen - nicht nur um sich zur Arbeit zu verpflichten, sondern auch um zu verstehen, wie man mit seinen Teamkollegen arbeitet. Wenn sich Leute über mangelnde Zusammenarbeit in ihrem Scrum-Team beschweren, betrachte ich gerne ihre Sprint-Planung als Teil des Problems

Überprüfung - Sammeln Sie Feedback vom Kunden zu dem, was wir bauen und was immer noch relevant ist usw. Dient auch als Qualitätsprüfung.

Rückblick - Verbessern Sie die Art und Weise, wie wir als Team zusammenarbeiten.

Wenn wir uns bemühen, den tieferen Zweck zu erfüllen, verschwindet normalerweise das Overhead-Problem. Wie in den ursprünglichen Kommentaren zur Frage erwähnt, skalieren die Zeremonien im Allgemeinen linear.

Wenn Sie mehr zu diesem Thema benötigen, habe ich einen Artikel: Auswählen einer Sprintlänge

— Mark Levison
quelle