Warum ich Storypunkte nicht für die Sprintplanung verwende

Hi, Habr! Ich präsentiere Ihnen die Übersetzung des Artikels "Warum ich Storypunkte nicht für die Sprintplanung benutze" von Mike Cohn.

Wie in Agile Estimating and Planning beschrieben, bin ich ein großer Fan von Story-Punkten, um den Rückstand eines Produkts zu bewerten. Ich empfehle jedoch auch, den Rückstand eines Sprints in Stunden und nicht in Storypunkten zu bewerten. Warum ist dieser scheinbare Widerspruch? Ich habe zuvor über die Gründe geschrieben. Ich empfehle die Verwendung unterschiedlicher Maßeinheiten (Punkte und Stunden) für verschiedene Rückstände.

Mir wird jedoch oft eine verwandte Frage gestellt, die ich hier stellen möchte:

Ich bin neugierig, warum Sie keine Story-Punkte verwenden, um einen Sprint zu planen. Ich dachte, dass das Messen von Geschwindigkeit in Storypunkten zum Teil dazu bestimmt ist, zu bestimmen, wie viel wir im Sprint nehmen können (oder korrigieren können). Verwenden Sie Story Point nur für die langfristige Planung (z. B. die Releaseplanung)?

Ich verwende keine Story-Punkte für die Sprintplanung, da Story-Punkte eine nützliche langfristige Maßnahme sind. Punkte sind jedoch kurzfristig nicht nützlich.

Es wäre angemessen für das Team zu sagen: "Wir haben eine durchschnittliche Geschwindigkeit von 20 Story-Punkten, und wir haben noch 6 Sprints, so dass wir in diesen sechs Sprints etwa 120 Story-Punkte haben werden."
Es wäre unangemessen für das Team zu sagen: "Wir haben eine durchschnittliche Geschwindigkeit von 20 Story-Punkten, also werden wir im nächsten Sprint enden." Es geht nicht.

Angenommen, die Basketballmannschaft befindet sich mitten in der Saison. Bis heute haben sie 41 Spiele gespielt und durchschnittlich 98 Punkte pro Spiel erzielt. Es wäre angebracht zu sagen: "In der verbleibenden Saison werden wir wahrscheinlich 98 Punkte pro Spiel erzielen." Sie sollten jedoch nicht vor einem bestimmten Spiel sagen: "Wir haben einen Durchschnitt von 98, also nehmen wir heute 98." Deshalb sage ich, dass Geschwindigkeit ein nützlicher langfristiger Prädiktor ist, aber kein nützlicher kurzfristiger Prädiktor.

Die Geschwindigkeit variiert von Sprint zu Sprint.

Deshalb möchte ich, dass die Teams ihre Sprints planen, den Rückstand des Produkts betrachten, eines der wichtigsten Dinge auswählen, das sie tun können, dieses Element / User Story-Rückstand des Produkts in Aufgaben aufteilen und die Aufgaben bewerten und sich fragen, ob sie es annehmen können Verpflichtungen zur Freigabe dieses Artikel Backlog-Produkts und dann wiederholt, bis sie gefüllt sind. Keine Diskussion von Story-Punkten. Keine Schnelldiskussion. Wir sprechen nur über Verpflichtungen und wir entscheiden, wie viel wir erreichen können, wenn wir die Produktrückstände in Aufgaben aufteilen und bewerten.

Wenn ein Team auf diese Weise einen Sprint geplant hat, ist es wahrscheinlich, dass die Anzahl der Story-Punkte, die es unwissentlich verfolgt, nahe an seinem Durchschnitt liegt. Dies wird sich jedoch ändern.

Es ist auch wahr, dass das Team von Sprint zu Sprint ungefähr die gleiche Anzahl von Stunden durchführt. Ich verwende den Begriff „Kapazität“, um auf diese Stundenzahl zu verweisen, da sich Geschwindigkeit auf die Messung des geplanten oder abgeschlossenen Arbeitsvolumens bezieht, wie in den Einheiten angegeben, mit denen der Rückstand des Produkts geschätzt wird (was ich empfehle, Story-Punkte zu verwenden ).

Über den Autor: Mike Cohn ist einer der Autoren der Scrum-Softwareentwicklungsmethodik. Er ist einer der Gründer der Agile Alliance und der Scrum Alliance. Er ist darauf spezialisiert, Unternehmen bei der Implementierung und Verbesserung des Einsatzes von agilen Prozessen und Methoden zum Aufbau von Hochleistungsteams zu unterstützen.

Referenzen: Agile Schätzung und PlanungMike Cohn, 2005.

PS Bewerten Sie den Sprint-Rückstand in Stunden oder Story-Punkten?

Jetzt auch beliebt: