Wer sollte am Sprint Replanning teilnehmen?

Es ist klar, dass beim Sprint Planning der Product Owner anwesend sein muss. Da das Entwicklungsteam jedoch für die aktuelle Sprintarbeit verantwortlich ist, muss der PO an der Neuplanung teilnehmen? Obwohl das Sprint-Ziel wahrscheinlich geändert wird, weiß nur das Entwicklerteam, wie viel Arbeit es aufnehmen kann, und wird daher den Sprint basierend auf seinem Wissen ändern.

Antworten (2)

TL;DR

[Da das Entwicklungsteam für die aktuelle Sprint-Arbeit verantwortlich ist, muss der PO an der Neuplanung teilnehmen? [sie]

Ja, der Product Owner muss bei allen Scoping- und Planungssitzungen anwesend sein.

Eine Anpassung des Umfangs innerhalb eines Sprints ist möglich, jedoch nur unter vollständiger Beteiligung des Product Owners. Änderungen am Sprint-Ziel sollten eine vorzeitige Beendigung des aktuellen Sprints und eine Rückkehr zur Sprint-Planung auslösen.

So ändern Sie den Umfang und die Sprint-Ziele in Scrum

Es gibt keine solche Zeremonie wie „Sprint Replanning“. Es hört sich so an, als hätten Sie eine spezielle Zeremonie zum Abschneiden des Umfangs des aktuellen Sprints erstellt, aber Scrum unterstützt diesen Prozess bereits im Standardrahmen.

Das Einschränken des Umfangs innerhalb eines Sprints ist sicherlich möglich, aber:

  1. Der Product Owner muss eingebunden werden. Ohne Beteiligung des Product Owners können keine Änderungen am geplanten Umfang vorgenommen werden.
  2. Änderungen am Sprint-Ziel dürfen nur mit vollständiger Zustimmung des Product Owners vorgenommen werden. Das Sprint-Ziel stellt eine geplante Wertsteigerung dar, sodass das Entwicklungsteam das Sprint-Ziel nicht einseitig ändern kann.
  3. Eine Änderung des Sprint-Ziels sollte eine vorzeitige Beendigung durch den Product Owner und eine Rückkehr zur Sprint-Planung auslösen. Wenn das zentrale Ziel eines Sprints aus irgendeinem Grund ungültig wird, muss es nach einer kurzen Sprint-Retrospektive vom gesamten Scrum-Team (einschließlich des Product Owners) verworfen und neu geplant werden, um festzustellen, was schief gelaufen ist.

Kurz gesagt, das Entwicklungsteam darf den Umfang nicht einschränken oder Ziele ohne die aktive Beteiligung des Product Owners ändern. Dies untergräbt die Kernverantwortung der Rolle des Product Owners und entfernt wesentliche Projektkontrollen aus dem Framework.

Das fühlt sich für mich sehr triggerglücklich an. Ja, der PO sollte informiert werden, wenn der Umfang abnimmt, und gefragt werden, was aus dem Sprint fallen kann, aber eine vorzeitige Beendigung auszulösen, ist sehr prozessintensiv. Entwickler werden ständig abgeworben und Geschichten erweisen sich gelegentlich als größer als gedacht. Es ist weniger störend, sich ohne die ganze Zeremonie zu treffen und die Verringerung des Umfangs zu besprechen. Außerdem gibt es keinen Grund, warum die Umfangsverringerung nicht Thema in der bereits geplanten Retrospektive sein könnte.
Der Scrum Guide stimmt mit Nr. 2 und Nr. 3 überein, aber nicht mit Nr. 1. Der Zweck des Sprint-Ziels besteht darin, das Entwicklungsteam zu verlangsamen, den Umfang ohne PO-Intervention zu ändern.
@MrHinsh Das ist falsch. Das Sprint-Ziel soll Implementierungsdetails leiten und dem Entwicklungsteam nicht erlauben, den Umfang einseitig zu ändern. Tatsächlich heißt es im Scrum Guide ausdrücklich: „Es werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden würden“ ( The Scrum Guide , 2013; S. 7), das während des Sprint Plannings für das aktuelle Inkrement definiert wurde. Wenn Sie diesbezüglich immer noch Unklarheiten haben, würde ich Ihnen dringend empfehlen, eine neue Frage zu eröffnen, damit Sie gründlichere Antworten zu diesem verwandten Thema erhalten.
Gut gesagt @CodeGnome. Das ist genau richtig und demonstriert die Flexibilität des Scrum Frameworks, um das Prinzip der Agilität zu unterstützen, das besagt: „Begrüßen Sie sich ändernde Anforderungen, auch spät in der Entwicklung. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.“

Tolle Frage. Meiner Erfahrung nach muss der Product Owner immer dann einbezogen werden, wenn Sie entweder den Sprintumfang oder das Sprintziel anpassen. Ich betrachte das Scrum-Team als das „Lieferteam“, und das Lieferteam liefert alles, was der Product Owner als die wertvollste Arbeit bestimmt hat. Sobald Sie also das Anpassen des Sprintziels sagen, denke ich: „Okay, der Product Owner hat das letzte Sprintziel festgelegt, wir sollten ihn wissen lassen, dass wir es nicht erreichen können und neu planen müssen.“ Auch wenn das Sprint-Ziel intakt ist und Sie wirklich nur einen Kapazitätsabfall haben (vielleicht wurde ein Entwickler abgeworben), sollte der Product Owner bestimmen können, welches Arbeitselement aus dem Sprint fallen kann. Sinn ergeben?

Wer sollte am Sprint Replanning teilnehmen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v