Kapazitätsgesteuerte Sprintplanung

Ich habe vor kurzem als Scrum Master für ein Team übernommen.

Ich plane die Implementierung einer kapazitätsgesteuerten Sprintplanung.

Die Herausforderung besteht darin, dass wir mehrere User Storys haben (die meiner Meinung nach als Aufgaben hätten klassifiziert werden sollen), die in mehrere Sprints übernommen wurden.

Nehmen wir an, ich habe 3 "User Stories", die sich aufgrund ihrer monolithischen Natur, der Ungenauigkeit der Anforderungen und der unvermeidlichen Erweiterung der Arbeit jeweils in mindestens 3 kontinuierliche Sprints ausgebreitet haben.

Wäre meine erste Aufgabe, den PO und das Team zusammenzubringen, um diese Art von User Stories während des Groomings aufzuteilen?

Es scheint, dass der erste Schritt bei der Implementierung einer kapazitätsgesteuerten Sprintplanung darin besteht, den Rückstand in Elemente zu kürzen, die dem INVEST-Ideal entsprechen, damit wir Elemente angemessen in die Kapazität einpassen können.

Bin ich auf dem richtigen Weg?

Warum sollten diese "monolithischen" Geschichten Ihrer Meinung nach als Aufgaben klassifiziert werden? Aufgaben sind immer kleiner als Geschichten.
@Llewellyn, einfach per Definition. Die Items bieten keinen direkten Benutzerwert, dh als DevOps möchte ich einen weiteren Server hinzufügen, um beim Load-Balancing zu helfen, ich habe es immer als Tasks mit Untertasks klassifiziert, falls erforderlich.
@MarkSaluta "As DevOps" ist nicht einmal eine Geschichte. DevOps wollen bezahlt werden. Das ist ihre Geschichte. Sie können ein super glückliches Leben ohne Lastenausgleich führen. Schreiben Sie keine „Als Pferd möchte ich den Karren zum Markt ziehen“-Geschichten. Das will das Pferd nicht. Beginnen Sie stattdessen damit, „Als Kaufmann“-Geschichten zu schreiben.
@nvoigt Würdest du dann sagen: Als Benutzer möchte ich, dass der Produktbildschirm 50% schneller geladen wird, damit ich schneller zur Kasse gehen kann. Eine Teilaufgabe davon könnte darin bestehen, einen weiteren Server hinzuzufügen, um beim Lastenausgleich zu helfen. Das klingt ungefähr richtig?
Klar, das hört sich gut an.
@MarkSaluta Stellen Sie einfach sicher, dass das Entwicklerteam derjenige ist, der die Geschichte aufteilt, und dass das Aufteilen dem PO gut erklärt wird, damit sie eine vereinbarte Sichtbarkeit der am Ende des Sprints erledigten Aufgaben bieten können.

Antworten (3)

Ich denke, Sie sind auf dem richtigen Weg, die Arbeitselemente aufzuschlüsseln. Hier ist, was Sie tun können

Option 1: Wenn User Stories auf „Geschäftsbedarf“ basieren, teilen Sie sie nicht weiter auf. Aber erstellen Sie sinnvolle Aufgaben aus den Eingaben des Teams. Erstellen Sie basierend auf der Verfügbarkeit jedes Teammitglieds Aufgaben, die innerhalb eines Sprints erreichbar sind. Stellen Sie sicher, dass die „Definition of Done“ für Aufgaben und User Story in Grooming-Meetings in Absprache mit dem Product Owner definiert wird.

Option 2: Erstellen Sie „Funktionen“ basierend auf „Geschäftsabsicht“. Erstellen Sie Sub-User-Storys basierend auf der „Kapazität“ des Teams. Jedes Sprint-Team kann die User Stories dimensionieren. Stellen Sie sicher, dass das Team während der Pflege die Kriterien für die „Messung des Fortschritts“ der User Story definiert. Zum Beispiel, wenn das Team die Größe der User Story = 10 Punkte festlegt. Das Team ist sich einig, dass es jeden Tag einen Fortschritt von 0,5 Punkten machen kann, dann können Sie den Fortschritt der Arbeit auf täglicher Basis leicht verfolgen.

Hoffe das hilft.

Dein Ansatz ist gut.

Wäre meine erste Aufgabe, den PO und das Team zusammenzubringen, um diese Art von User Stories während des Groomings aufzuteilen?

Es würde sich lohnen, einige Zeit damit zu verbringen, das Team zu coachen, um zu verstehen, warum ihre Geschichten verbessert werden müssen.

Außerdem versuche ich als Scrum Master Dinge zu vermeiden wie:

"Ich plane die Implementierung einer kapazitätsgesteuerten Sprintplanung."

"... meine erste Aufgabe wäre es, den PO und das Team zusammenzubringen".

Stattdessen würde ich sagen:

"Ich werde dem Team empfehlen, kapazitätsgesteuerte Sprintplanung auszuprobieren"

"...meine erste Aufgabe wäre es, dem Team zu empfehlen, sich zusammenzusetzen und ihm zu erklären, warum es sinnvoll wäre."

Der Ton, in dem ein Scrum Master das Team anspricht, ist wichtig. Es ist eher eine dienende Führungsrolle als eine Managementrolle .

Danke für das. Es ist eine großartige Erinnerung und etwas, das man jeden Tag im Auge behalten sollte.

Wenn sie überschwappten, weil die Anforderungen zu vage waren und die Arbeit ausgeweitet wurde, dann würde ich sagen, dass das Team bei der Verfeinerung der Akzeptanzkriterien nicht sorgfältig genug war.

Ich würde sagen, sie aus dem Sprint zu nehmen und ihren Status von wo auch immer sie jetzt sind (zugesagt oder bereit oder was auch immer) auf „genehmigt“ zurückzusetzen. Lassen Sie an diesem Punkt das Lieferteam und die Beteiligten zusammenarbeiten, um zu sehen, was eliminiert werden kann, um etwas in einem Sprint zu liefern, und legen Sie die Akzeptanzkriterien fest. Vielleicht geht eine Story noch über einen Sprint hinaus, aber versuchen Sie, Akzeptanzkriterien bei allen Beteiligten festzulegen, damit:

  • Entwickler wissen, was zu tun ist, und können den Fortschritt einfach über Aufgaben aus AC weiterleiten
  • Tester wissen, was sie testen müssen, wenn es sie erreicht. Sie können möglicherweise in einer Testumgebung bereitstellen und sagen: „Hey, können Sie einen Blick darauf werfen, ich glaube, ich habe die Kriterien 1, 2 und 3 erfüllt“. Es hilft Entwicklern und QA bei der Zusammenarbeit und gibt dem Team Transparenz über den Fortschritt

Seien Sie vorsichtig, wenn Sie nur "aufschneiden". Stellen Sie nach Möglichkeit sicher, dass eine Geschichte einen geschäftlichen Wert liefert und nicht nur Teil von etwas Größerem ist, das einen geschäftlichen Wert hat (zu liefern, wer weiß wann).

Kapazitätsgesteuerte Sprintplanung
AntwortenHierDatenschutz-Bestimmungen1y, 0v