Was tun, wenn ein Mitglied eines Teams alle seine Sprint-Aufgaben vorzeitig beendet?

Ihnen stehen einige Optionen zur Verfügung.

• Nutzen Sie die verfügbare Zeit, um an technischen Schulden zu arbeiten oder Fehler zu beheben.
• Bitten Sie das Teammitglied, die Last eines anderen Teammitglieds zu teilen, um ihm/ihr beim Abschließen des Sprint-Backlogs zu helfen, da es sich um ein funktionsübergreifendes Team handelt und es ihre gemeinsame Verantwortung/Verpflichtung ist, Sprint-Elemente als Team zu liefern.
• Wählen Sie das Element mit der nächsthöchsten Priorität aus dem Backlog, nachdem Sie es mit dem Product Owner besprochen haben. Versuchen Sie, das Element in kleinere oder dünnere Stücke zu zerlegen, die tatsächlich im selben Sprint abgeschlossen werden können.

Sklivvz schrieb in dieser Antwort Folgendes :

Sie können Geschichten zu einem laufenden Sprint hinzufügen, wenn das Team damit einverstanden ist. Es ist jedoch keine gute Praxis, da es die Nützlichkeit und Vorhersagefähigkeit der Methodik verringert

Derselbe Ansatz wird auch in diesem Blogbeitrag erwähnt :

Ich empfehle Ihnen, eine Sitzung zur Produktpflege durchzuführen, die in diesem Fall als Sprintplanungssitzung für die kleine Menge an neuer Arbeit dient, die möglicherweise in die verbleibende Zeit passt. Wenn die neuen Product-Backlog-Elemente vor dem Ende des Sprints fertiggestellt werden, werden ihre entsprechenden Story-Punkte auf die Velocity angerechnet

Typischerweise haben wir bei Scrum ein Produkt-Backlog , das eine Liste der Arbeiten enthält, die wir in Zukunft zu erledigen erwarten.

Zu Beginn jedes Sprints setzen sich der Product Owner und das Team zusammen und besprechen, welche Storys aus dem Product Backlog in den Sprint übernommen werden sollen. Viele Teams verwenden eine Metrik namens Geschwindigkeit , um zu bestimmen, wie viel Arbeit in den Sprint eingebracht werden soll.

Nun läuft der Sprint nicht immer wie erwartet. Wenn es am Ende des Sprints unfertige Arbeit gibt, können wir unsere Geschwindigkeit reduzieren und so weniger Arbeit in zukünftige Sprints einbringen.

Wenn die dem Sprint zugewiesene Arbeit abgeschlossen ist, bevor der Sprint endet, gehen wir ähnlich wie folgt vor:

• Sprechen Sie mit dem Product Owner und prüfen Sie, ob es vorbereitete Storys im Product Backlog gibt, die möglicherweise in den Sprint eingebracht werden könnten.
• Wenn wir mehr Arbeit hineinbringen und sie bis zum Ende des Sprints abschließen, wird die Geschwindigkeit normalerweise zunehmen und wir werden daher mehr Arbeit in zukünftige Sprints hineinbringen.

Erfahrene Scrum-Teams sorgen oft dafür, dass die Storys ganz oben im Product Backlog klein und startklar sind. Auf diese Weise ist es einfach, mehr Arbeit einzubringen, wenn sie die dem Sprint zugewiesene Arbeit früher erledigen.

Sie sind ein PM, der Einzelpersonen Aufgaben zuweist. Sie haben das Wort Sprint verwendet, aber ist nicht Scrum, was ist es?

Die Scrum-Antwort wäre, dass das Mitglied des Entwicklungsteams zu jeder Aufgabe übergeht, die dem Team hilft, seine Verpflichtungen zu erfüllen. Ob es darum geht, „die Aufgabe eines anderen“ zu übernehmen (das ist keine Sache in Scrum) oder Paarung. Die Sache mit der Paarung ist, dass, wenn dem Teammitglied die Fähigkeiten fehlen, einem anderen zu helfen, dies ihm hilft, sie zu erwerben.

Ich würde davon abraten, mehr Arbeit zu ziehen, bis das Team Kapazität hat, nicht nur eine Einzelperson. Verbessern Sie die Zusammenarbeit, damit alle zuerst an der aktuellen Arbeit arbeiten können.

Nun, zunächst einmal sollten Sie abwarten, ob dies ein einmaliger Vorgang ist. Wenn dies häufiger vorkommt, besprechen Sie mit dem Team, warum sie sich auf diese Menge an Story Points festlegen, obwohl es offensichtlich ist, dass sie mehr bewältigen könnten.

Auch ein kleines RnD-Projekt ist eine Option, die in solchen Fällen bearbeitet werden kann. Vielleicht ist es aufgrund einiger strategischer Ziele sinnvoll. Es ist auch eine gute Motivation, denke ich.

Um ehrlich zu sein, habe ich ein solches Szenario noch nie erlebt, da wir hier eine Bug-First-Richtlinie haben, die normalerweise ungeplante Anstrengungen sind und daher die Menge an verfügbarer Funktionsentwicklungszeit verringern.

Bearbeiten

Wie ich in den Kommentaren sagte, optimiert es die Leistung durch Wiederholung. Das Beste an Scrum ist, dass es eine Absprache zwischen PM und DEV gibt, die auf Augenhöhe getroffen wird. Diese Vereinbarung muss angepasst werden, damit am Ende nichts übrig bleibt und keine Zeit verschwendet wird. Es ist normal, dass die Vereinbarung am Anfang nicht ideal ist, aber früher oder später wird sie es definitiv werden.

Wenn Sie jetzt von Ihrer Website aus optimieren, indem Sie ihnen innerhalb des Sprints eine zusätzliche Geschichte geben, ist dies eine normale hierarchische Situation und kann die Motivation des Teams verringern.

Seien Sie also geduldig und lassen Sie das Team seine Lektionen lernen, so wie Sie Ihre lernen müssen. Nehmen wir an, in Woche 1 beträgt die Verpflichtung 30 SP und sie sind bis Donnerstagmorgen erledigt. In Woche 2 könnte die Verpflichtung dann 40 SP betragen. Jetzt konnten sie nicht fertig werden. Kein Problem, in Woche 3 sollte der Einsatz 35 SP betragen. Leistung optimiert mit 3 Wochen. Natürlich stehen Sie vielleicht vor dem Problem, dass Sie zwar ein „ideales“ Engagement gefunden haben, das Ergebnis aber alles andere als ideal ist. Aber auch das ist normal, da man es mit Menschen und nicht mit Maschinen zu tun hat.