Hallo Habr! Ich präsentiere Ihnen die Übersetzung des Artikels
„Warum ich keine Story Points für die Sprintplanung verwende“ von Mike Cohn.
Wie in Agile Estimating and Planning beschrieben, bin ich ein großer Fan von Story Points für die Bewertung von Produktrückständen. Ich empfehle jedoch auch, den Sprint-Rückstand in Stunden anstatt in Story-Punkten auszuwerten. Warum ist dieser offensichtliche Widerspruch? Früher habe ich über die Gründe geschrieben. Ich empfehle die Verwendung unterschiedlicher Maßeinheiten (Punkte und Stunden) für unterschiedliche Rückstände.
Aber mir wird oft eine verwandte Frage gestellt, die ich hier stellen möchte:
Ich bin gespannt, warum Sie keine Story Points für die Sprintplanung verwenden. Ich dachte, dass der Punkt der Geschwindigkeitsmessung in Story-Punkten teilweise darin bestand, zu bestimmen, wie viel wir im Sprint nehmen (oder reparieren) können. Verwenden Sie nur Story Points für die langfristige Planung (z. B. Release-Planung)?Ich verwende keine Story Points für die Sprintplanung, da Story Points eine nützliche langfristige Maßnahme sind. Aber Punkte sind kurzfristig nicht sinnvoll.
Es wäre angemessen, wenn das Team sagen würde: "Wir haben eine Durchschnittsgeschwindigkeit von 20 Story-Punkten und wir haben noch 6 Sprints, also werden wir in diesen sechs Sprints ungefähr 120 Story-Punkte beenden."
Es wäre für das Team unangemessen zu sagen: "Wir haben eine Durchschnittsgeschwindigkeit von 20 Story Points, also werden wir im nächsten Sprint fertig sein." Das funktioniert nicht.
Angenommen, die Basketballmannschaft befindet sich mitten in ihrer Saison. Bisher haben sie 41 Spiele gespielt und durchschnittlich 98 Punkte pro Spiel erzielt. Es wäre angebracht zu sagen: "Wahrscheinlich werden wir im Rest der Saison durchschnittlich 98 Punkte pro Spiel erzielen." Aber sie sollten vor keinem bestimmten Spiel sagen: "Wir haben einen Durchschnitt von 98, also werden wir heute 98 nehmen." Deshalb sage ich, dass Geschwindigkeit ein nützlicher Langzeitprädiktor ist, aber kein nützlicher Kurzzeitprädiktor.
Die Geschwindigkeit variiert von Sprint zu Sprint.
Aus diesem Grund möchte ich, dass Teams ihre Sprints planen, indem sie sich das Produkt-Backlog ansehen, eines der wichtigsten Dinge auswählen, dieses Element / diese User Story des Produkt-Backlogs in Aufgaben aufteilen und die Aufgaben bewerten und sich fragen, ob sie diese übernehmen können Zusagen, diesen Rückstand des Produkts freizugeben und dann zu wiederholen, bis sie gefüllt sind. Keine Diskussion über Story Points. Keine Diskussion über Geschwindigkeit. Es ist nur eine Frage der Verpflichtungen, und wir entscheiden, wie viel wir erfüllen können, indem wir Punkte des Produktrückstands in Aufgaben aufteilen und diese bewerten.
Wenn das Team die Planung des Sprints auf diese Weise abgeschlossen hat, ist es wahrscheinlich, dass die Anzahl der Story-Punkte, die sie unwissentlich verfolgen, nahe an ihrem Durchschnittswert liegen sollte, aber sie wird sich ändern.
Es wird auch wahr sein, dass das Team von einem Sprint zum nächsten ungefähr die gleiche Anzahl von Stunden absolviert. Ich verwende den Begriff „Kapazität“, um mich auf diese Anzahl von Stunden zu beziehen, da die Geschwindigkeit für eine Messung des Volumens geplanter oder abgeschlossener Arbeiten reserviert ist, wie in den Einheiten angegeben, die zur Bewertung des Produktrückstands verwendet werden (die ich zur Verwendung von Story Points empfehle )
Über den Autor: Mike Cohn ist einer der Autoren der Scrum-Softwareentwicklungsmethode. 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 agiler Prozesse und Methoden zur Schaffung von Hochleistungsteams zu unterstützen.
Referenzen:
Agile Schätzung und Planung , Mike Cohn, 2005.
PS Bewerten Sie den Sprint-Rückstand in Stunden oder Story-Punkten?