Der Sprint wird halten! ... oder wie man mit Sprint-Overload umgeht

Wie Sie wahrscheinlich erlebt haben, Eine Sprint-Überlastung kann das Team stark beeinträchtigen. Die Teammitglieder nehmen die Planungen möglicherweise nicht mehr ernst, werden gestresst und beeilen sich — was oft zu Versäumnissen führt. Irgendwann wird Mikromanagement unverzichtbar und das Team verliert an Glaubwürdigkeit.

Das Problem ist viel zu schwer, als dass der Ratschlag „Hör auf damit“ funktionieren könnte.

Aber glücklicherweise kann das Problem der Sprint-Überlastung effektiv gelöst werden, wenn es richtig angegangen wird.

Bereit für die Geschichte eines Teams, das monatelang mit der Überlastung zu kämpfen hatte und sie in 6 Schritten überwunden hat? Dann lass uns eintauchen.

<span class="colorbox1" fs-test-element="box1"><p>Projekt: Business Intelligence - Versicherung</p> <p>Team: 6 Personen</p> <p>Rahmen: Scrum</p></span>

„Wir müssen es immer noch machen“ also... lass uns den Backlog von Sprint stopfen, als wäre es ein Feiertagstruthahn!

Unser Team hatte ein Problem: Sprint-Pläne waren ständig überlastet mit Aufgaben, die bis zum Ende des Sprints unmöglich erledigt werden konnten.

Den Backlog von Sprint zu stopfen, als wäre es ein Feiertagstruthahn — je mehr desto besser — ist eine seltsame und gefährliche Art der Planung, aber es passiert viel zu oft.

Um kein Missverständnis zu verursachen: Jeder Sprint-Plan sollte so viele Ressourcen wie möglich nutzen, die dem Team für den Sprint zur Verfügung stehen. Das Problem tritt auf, wenn Sie übersteigen Sie die Kapazität Ihres Teams um 50%, 100%, oder noch mehr.

Sprint-Überlastungen treten häufig auf, weil:

• hoher Geschäftsdruck den Teams das Gefühl geben, dass sie keine andere Wahl haben, als alle Aufgaben anzunehmen und zu erledigen, da sie sonst mit schwerwiegenden Konsequenzen konfrontiert werden,
• Teams zu optimistisch einschätzen — entweder um den Interessengruppen zu gefallen oder weil sie nicht ausreichend geschult wurden,
• Product Owner haben Angst vor der unzureichenden Nutzung der verfügbaren Ressourcen (Zeit, Fähigkeiten der Mitarbeiter usw.) und der potenziellen Budgetverschwendung.

Verlängert das Überfüllen des Plans für den Sprint auf magische Weise die Zeit, die Sie dafür haben? Darauf würde ich nicht zählen.

Folgen einer Sprint-Überlastung: Wie scheitern falsche Pläne?

Leider führt eine ständige Sprint-Überlastung schnell zu einem solchen Denken:

• Ein Team nimmt Pläne nicht ernst.
• Sie legen sich nicht auf Pläne fest.
• Und sie sind nicht glaubwürdig, wenn sie sie formen.

Infolgedessen halten Stakeholder und der Product Owner den Plan des Teams nicht für glaubwürdig. Sie halten den Druck auf das Team aufrecht, diese Pläne als einzige Möglichkeit zu betrachten, um sicherzustellen, dass niemand ohne Aufgabe ist (gruselige Geräusche).

Wenn Pläne nicht umgesetzt werden können, was ist dann der Anreiz für jedes Teammitglied, so viele PBIs (Product Backlog Items) auf FERTIG zu stellen, bevor der Sprint endet? Eingeschränkt oder gar nicht. Das Team ist Konzentrieren Sie sich aufs Tun statt auf das Erbringen, und weder die tatsächliche Geschwindigkeit noch die Kapazität sind bekannt.

Lösung? Immer dasselbe: damit aufzuhören. Aber es ist nicht so einfach, wie es sich anhört.

6 Schritte, um das Überladen ein für alle Mal zu stoppen

Unser Scrum Master hat beschlossen, das Problem der Überlastung effektiv und ein für alle Mal zu lösen.

Der Plan wurde erstellt und der erste Schritt bestand darin, mit dem gesamten Team und dem Product Owner zu sprechen. Aber lassen Sie uns nicht überholen.

Schließlich waren es 6 Schritte, um aus der Überlastungsfalle herauszukommen. Hier sind sie:

Schritt 1: Entwickeln Sie ein gemeinsames Verständnis für ein Problem

Scrum Master begann damit, das gesamte Team und den Product Owner zu coachen was ist passiert, als sie weit über die Kapazität hinaus planten. Das Problem war, dass das Team seine Glaubwürdigkeit ruinierte. Ihren Plänen konnte nicht vertraut werden, was sowohl vom Product Owner als auch von den Stakeholdern zu einem Mikromanagement führte. Wenn sie einen sehr wichtigen Sprint planen würden, wüssten sie nicht, wie viel sie tatsächlich liefern könnten.

Schritt 2: Verwenden Sie Geschwindigkeitsmesswerte, um einen konkreten Plan zu erstellen

Die Geschwindigkeitswerte waren höchstwahrscheinlich niedriger als die Möglichkeiten des Teams, aber sie wurden vom Scrum Master als Ausgangswert betrachtet, auf dessen Grundlage das Team den nächsten Sprint planen sollte. Er fragte sehr nachdrücklich keinen einzigen Punkt über der aktuellen Geschwindigkeit des Teams zu planen. Das bedeutete zwar, dass das Team sicherlich zu wenig liefern würde, aber die wichtigste Idee dahinter war, einen konkreten Plan zu erstellen und ihn vollständig umzusetzen.

Schritt 3: Konzentrieren Sie sich auf die täglichen Besprechungen

Während des Sprints konzentrierte sich der Scrum Master stark auf die täglichen Besprechungen und darauf, zu überprüfen, ob die Teammitglieder Konzentrieren Sie sich darauf, Aufgaben zu schließen, anstatt neue zu eröffnen. Dazu wies er auf die Aufgaben hin, die von niemandem erwähnt wurden, die überprüft, getestet oder veröffentlicht werden mussten, aber niemand wählte sie für diesen Tag aus — und bat darum, sie vor neuen Aufgaben auszuwählen.

Schritt 4: Neue Aufgaben nur öffnen, wenn nichts anderes möglich ist

In der zweiten Hälfte des Sprints bat er die Teammitglieder darum, sie zu erledigen, auch wenn es keine Aufgaben zu überprüfen, zu testen oder zu veröffentlichen gab Paarprogrammierung wenn möglich, und neue Aufgaben nur dann zu öffnen, wenn nichts anderes möglich war.

Schritt 5: Geschwindigkeit neu berechnen

Das Team hat den gesamten Sprint-Plan geliefert und sie musste in den letzten Tagen des Sprints noch etwas mehr aus dem Produkt-Backlog mitnehmen. Die Geschwindigkeit ist etwas gestiegen und wurde neu berechnet.

Schritt 6: Wiederholen, Daten sammeln und lernen

Derselbe Vorgang wurde für einige Sprints wiederholt, bis das Team echte Daten über seine Geschwindigkeit hatte und sie lernten, darauf basierend zu planen.

Ergebnisse

Nach mehreren Sprints hat sich die Situation stabilisiert. Die Pläne des Teams wurden als glaubwürdig erachtet, was senkte jegliches Mikromanagement auf ein Minimum. Die Beteiligten hatten ein viel klareres Verständnis davon, was mit dem Team im Laufe der Zeit erreicht werden konnte, und sie übten keinen Druck auf das Team aus, wenn ihre Zuschläge ihren Plänen entsprachen.

Der Scrum Master trainierte das Team zu plane immer etwas mehr als die Kapazität ein und habe immer ein paar freie Aufgaben, keine Must-haves, für die letzten Tage des Sprints, um zusätzliche Planungssitzungen mit dem Product Owner zu vermeiden.

Umgang mit Sprint-Überlastung und Planung — Tipps von Branchenexperten

Jedes Projekt, jedes Team und jeder Fall ist anders.

Nur weil sich ein Ansatz für mehrere Teams als erfolgreich erwiesen hat, ist er noch lange keine Universallösung.

In diesem Bereich ist praktische Erfahrung von entscheidender Bedeutung.

Aus diesem Grund haben wir 3 hoch angesehene Experten gefragt, was sie über den Umgang mit Sprint-Überlastungen und effektiver Planung denken.

Frage 1: Was ist Ihrer Erfahrung nach der beste Ansatz, um mit Sprint-Überlastung umzugehen?

Gagik Sukiasjan, Group Sr. Manager, Software Engineering bei Adobe, sagt:

<blockquote><p>Ich denke, es ist am besten, neben der Geschwindigkeitsplanung mit einer detaillierten Kapazitätsplanung zu beginnen. Zum Beispiel verwenden die Teams, mit denen ich zusammenarbeite, einen Kalkulationsrechner, der auf Tabellen basiert, um ein besseres Verständnis unserer Allokation und der verfügbaren Kapazität zu erhalten. Sobald wir unsere Kapazität und Geschwindigkeit gemessen haben, stellen unsere Product Owner sicher, dass die Summe der Story Points in unserem Sprint-Backlog nur geringfügig über der Durchschnittsgeschwindigkeit der Teams liegt</p></blockquote>.

<span class="colorbox1" fs-test-element="box1"><p><strong>Bonus-Ressource:</strong></p> <p>Gagik Sukiasyan hat freundlicherweise seine Tabellenkalkulationsvorlage unter dem unten stehenden Link geteilt — schauen Sie sie sich unbedingt</p> an. <p>Laden Sie den „Rechner für Geschwindigkeits- und Kapazitätsplanung“ herunter</p><p>Weitere Informationen zur Verwendung des Rechners finden Sie hier</p></span>.

Paweł Huryn, Produktleiter und Autor, teilt mit:

<blockquote><p>Es ist wichtig, sich darüber im Klaren zu sein, dass die für Sprint ausgewählten Product Backlog-Elemente keine Verpflichtung darstellen. Das einzige Ziel, auf das sich das Scrum-Team konzentrieren sollte, ist das Sprint-Ziel. Entwickler sollten ihre Fortschritte auf diesem Weg täglich überprüfen</p>. <p>Das Sprintziel muss Flexibilität bieten, sodass Entwickler bei Bedarf mit dem Product Owner darüber verhandeln können, wie es am besten erreicht werden kann.</p> <p>Meiner Meinung nach ist das regelmäßige Erreichen der Sprintziele eines der besten Messgrößen für die Gesundheit eines Teams. Fehler werden passieren, aber mit der Zeit werden sie lernen, ihre Arbeit immer besser zu planen. Der richtige Einsatz der Sprint Retrospective ist entscheidend</p></blockquote>.

Kevin Bendeler, Produktleiter bei Heroes Corp und Product Owner Digital Enterprise & User Experience bei Alliander, meint:

<blockquote><p>Für Product Owner ist es von grundlegender Bedeutung, eine Sprint-Überlastung zu vermeiden. Eine gute Faustregel lautet, im Sprint keine zusätzliche Arbeit auf sich zu nehmen, ohne etwas anderes fallen zu lassen. Es ist wichtig, dass diese neue Arbeit einen größeren Beitrag zum Sprintziel leistet als die Arbeit, die den Sprint beendet. Schließlich muss die Arbeit, die verworfen wird, noch nicht begonnen haben. Sie verlieren an Dynamik, wenn Sie bereits begonnene Arbeiten beenden, und noch mehr verlieren Sie, wenn Sie den Kontext wechseln</p></blockquote>.

Frage 2: Wenn Sie Ihre 3 wichtigsten Tipps für eine effektive Sprint-Planung geben würden, welche wären das?

Gagik Sukiasyan, Group Sr. Manager, Software Engineering bei Adobe, sagt:

<blockquote><p>Mein Rat ist, die Planung in vier Hauptphasen zu unterteilen:</p> <ol><li>Der Product Owner präsentiert das Sprint-Backlog und beschreibt den nächsten Schritt, den das Team erreichen sollte</li>. <li>Das Team schaut sich seine Geschwindigkeits- und Kapazitätswerte an, um seine Leistungsfähigkeit zu verstehen.</li> <li>Das Team teilt Storys in Unteraufgaben auf und weist ihnen stündliche Schätzungen zu. Wählt dann die Unteraufgaben aus, die in den Sprint aufgenommen werden sollen</li>. </ol></blockquote><li>Das Team und der PO schauen sich noch einmal die Sprint-Ziele an, passen sie an die Aufgaben an, die sie übernommen haben, und verpflichten sich, diesen Umfang einzuhalten.</li>

Paweł Huryn, Produktleiter und Autor, teilt mit:

<blockquote><ol><li>Führungskräfte führen mit Weitblick. Sie müssen also mit dem WARUM beginnen. Warum ist dieser Sprint wertvoll? Welchen Wert wird er für die Kunden und das Unternehmen schaffen? Wie wird es zu einer größeren Vision beitragen?</li> <li>Lassen Sie die Entwickler die Arbeit selbst in die Hand nehmen, anstatt sie in den Sprint zu verschieben. Insbesondere haben Entwickler das Recht, die wichtigsten Product Backlog Items abzulehnen, wenn sie sich nicht sicher sind, welchen Umfang sie haben oder ob sie sie umsetzen können</li>. <li>Geschwindigkeit ist, falls verwendet, eine interne Metrik. Sie sollte niemals außerhalb des Scrum-Teams geteilt werden</li></blockquote>.

Kevin Bendeler, Produktleiter bei Heroes Corp und Product Owner Digital Enterprise & User Experience bei Alliander, meint:

<blockquote><p>Die meisten Planungssitzungen drehen sich um die Arbeit. Das Ergebnis des Sprints wird dann als Ergebnis der Arbeit definiert. Diese Arbeitsweise führt unweigerlich zu fehlgeschlagenen Sprints, da jede Änderung bedeutet, dass Sie Ihr gewünschtes Ergebnis nicht erreichen. So kann man nicht leben</p>. <p>Als Product Owner willst du ein Ergebnis. Machen Sie Ihrem Team also deutlich, wie das Ergebnis aussieht. Das ist dein Anfang. Die Arbeit wird sich aus diesem Ergebnis ergeben. Du kannst deinen Backlog natürlich so anordnen, dass er dieses Ergebnis widerspiegelt, aber du solltest ständig darüber reden, wie du es am besten erreichst. Das bedeutet, dass eine Planungssitzung kurz sein kann und das Team während des gesamten Sprints flexibel bleibt. Ohne das ultimative Ziel aus den Augen zu verlieren.</p></blockquote>

Nächste Herausforderung: Wie man Tagespläne erstellt

Dieser Artikel hat uns gelehrt, dass Pläne in Agile, obwohl sie allgemein als zweitrangig angesehen werden, tatsächlich genauso wichtig sind wie im Waterfall-Ansatz — sie wurden nur für kurze Arbeitsschritte entwickelt.

Aber wenn man schon weiß, wie man den ganzen Sprint adäquat plant... entstehen Tagespläne und Besprechungen.

Wie Tagespläne erstellen, um die Durchführung von „Statusbesprechungen“ zu vermeiden? Sieht nach einer weiteren Herausforderung aus.

Das ist jedoch ein Thema für einen anderen Artikel, also bleiben Sie dran! Melde dich für unseren Newsletter an, um über die Veröffentlichung informiert zu werden.