Einige Scrum Master sind damit beschäftigt, die Geschwindigkeit eines Teams während eines Sprints zu „erhöhen“, als ob eine höhere Geschwindigkeit besser wäre. Aber Punkte sind ein relatives Maß für die Arbeit, die ein Team für Feature X leisten muss; Sie sind nicht hoch oder niedrig, sie sind nur mehr oder weniger als ein anderes Merkmal, das das Team willkürlich als Bezugspunkt ausgewählt hat. Wichtig ist, dass Sie Ihre Geschwindigkeit kennen, egal wie viele Punkte das sind.
Wenn Punkte Aufwand sind, strengt man sich mit der Zeit nicht mehr an. Sie machen den gleichen Aufwand, aber es ist produktiver. Eine Geschichte, die bei der Gründung des Teams auf fünf Punkte geschätzt wurde, könnte schließlich auf drei oder zwei Punkte geschätzt werden, wenn das Team seine Fähigkeiten verbessert.
Ist das korrekt? Ich sehe keinen Konsens darüber, ob Punkte Komplexität oder Aufwand messen, aber so oder so scheint es mir, dass der wahrgenommene Aufwand oder die Komplexität einer Aufgabe mit der Zeit sinken wird und Sie mehr davon in a unterbringen können sprinten und so deine Geschwindigkeit konstant halten.
Sollte die Geschwindigkeit mit der Zeit zunehmen?
Die vereinfachte Antwort lautet, dass die Geschwindigkeit eines Projekts nur so lange zunehmen sollte, bis das Team eine stabile, vorhersehbare Trittfrequenz entwickelt hat, die über die Zeit beibehalten werden kann. Es gibt natürlich ein paar Vorbehalte, aber es ist eine solide Faustregel.
Das Zielen auf einen unbestimmten Aufwärtstrend der Geschwindigkeit ist ein „Projektgeruch“, dass die Geschwindigkeitsmetrik missbraucht oder missverstanden wird. Das Erwarten eines solchen Trends ist oft ein Symptom für den Wunsch des Managements, auf die Schaltfläche „Schneller gehen“ zu drücken, ohne die Grenzen der nachhaltigen Kapazität eines Projekts oder Teams zu respektieren.
Die Geschwindigkeit ist ein Maß für die historische Kapazität eines Teams und kein direkt korreliertes Maß für die Geschwindigkeit oder Produktivität des Teams. Es sollte hauptsächlich während der Sprint-Planung verwendet werden, um die Sprint-Backlog-Kapazität für den bevorstehenden Sprint zu prognostizieren.
Die Kapazität eines Teams kann sich im Laufe der Zeit sicherlich ändern: Die Kapazität kann während Urlaubszeiten oder Umstrukturierungen sinken oder steigen, wenn Teams Domänenkenntnisse erlangen, iterative Verbesserungen an ihren testgetriebenen Designs nutzen oder technische Schulden tilgen.
Es ist jedoch ein Trugschluss anzunehmen, dass die Kapazität einen Aufwärtstrend haben kann oder sollte. Auch wenn sich der Kegel der Unsicherheit später in einem Projekt verengt, steigen die Kosten für technische Schulden und Refactorings im Allgemeinen, und diese Faktoren verbrauchen auch Teamkapazität. Darüber hinaus ist es nicht ungewöhnlich, dass die Komplexität von User Stories im Laufe der Zeit zunimmt, wenn die niedrig hängenden Früchte aus dem Product Backlog gepflückt werden. Auch diese zusätzliche Komplexität wird eine entsprechende Menge an Kapazität des Teams verbrauchen.
Das Ziel von Scrum (und der iterativen agilen Entwicklung im Allgemeinen) ist eine nachhaltige und vorhersehbare Entwicklungskadenz. Daher ist es im Allgemeinen besser, eine konstante Geschwindigkeit im Laufe der Zeit anzustreben, anstatt die Geschwindigkeit zu erhöhen .
Story Points messen eine Kombination aus Komplexität und Aufwand, was sie für Menschen schwer verständlich macht. Risiko und Ungewissheit sind wahrscheinlich auch Komponenten, die Teil der Schätzung sind.
Am Ende ist die Geschwindigkeit ein Maß dafür, was Sie in den letzten (wenigen) Sprints geliefert haben. Es ist ein Indikator dafür, was Sie im nächsten Sprint erwarten können, wenn sich nicht viel ändert.
Wir sehen jedoch, dass sich Scrum-Teams im Laufe der Zeit verbessern, sie werden besser in dem, was sie tun, sie automatisieren Dinge, die in jedem Sprint viel Zeit in Anspruch nehmen, sie erweitern ihr Wissen über die Domäne und sie beginnen, Code wiederzuverwenden Elemente aus früheren Sprints, auf denen aufgebaut werden kann.
Daher ist es normal, dass Teams ihre Velocity im Laufe der Zeit erhöhen. Oft erreicht diese Geschwindigkeit eine Obergrenze, ihre maximale Leistungsfähigkeit angesichts der aktuellen Umstände, und sie können ohne ein Großereignis nicht wieder mit dem Klettern beginnen. Dieses Ereignis kann eine Schulung, eine Änderung der Arbeitsweise, ein neues Teammitglied mit Schlüsselqualifikationen oder ein Wechsel von einer Technologie zu einer anderen (oder einfach ein Upgrade von vold auf vnew) sein.
Die meisten Teams wählen ein paar Referenzgeschichten aus. Einige wählen einfach ihre 1, 5 oder 8. Andere Teams wählen eine 5 und eine 20. Es spielt keine Rolle, was sie wählen. Anhand dieser Bezugspunkte vergleichen Sie die anderen Geschichten mit der ursprünglichen Anfrage. Daher ist die Anzahl der Story Points zwischen zwei Storys oft gleich, obwohl der genaue Aufwand im Laufe der Zeit drastisch gesunken ist. Aus diesem Grund kann ein Team seine Geschwindigkeit im Laufe der Zeit von 40 auf 200 erhöhen.
Wenn ein Team das Gefühl hat, dass es in den unteren Bereichen seiner Story Points nicht genug Granularität hat, kann es sich dafür entscheiden, 5 neue auszuwählen und alle anderen Elemente im Backlog entsprechend anzupassen.
Denken Sie daran, dass die Erhöhung der Geschwindigkeit nicht etwas ist, das wir ständig fördern sollten. Die Behandlung der Geschwindigkeit als Metrik hilft den Teams nicht zu verstehen, was sie tatsächlich tun können, und führt normalerweise zu schlechtem Verhalten, wenn es um Schätzungen geht. Stattdessen sollten Sie sich als Scrum Master darauf konzentrieren, Verschwendung zu beseitigen und den pro Sprint gelieferten Wert zu steigern. Wenn das Team den gleichen Fokus hat, wird seine Velocity dadurch steigen.
Story Points sind ein relatives Maß für den Aufwand. Mit der Zeit kann ein Team besser darin werden, Dinge zu tun. Aber das bedeutet nicht zwangsläufig, dass aus einer 5-Punkte-Story eine 3-Punkte-Story wird. Hier ist ein Beispiel:
Story X beinhaltet das Schreiben einer Suchfunktion auf einer Webseite und wird vom Team mit 5 Punkten bewertet. Story Y ist eine Einstellung zum Ausblenden von Bildern auf einer Webseite und wird vom Team auf 3 Punkte geschätzt, da sie im Vergleich zu Story X kleiner ist.
Nehmen wir nun an, dass sich das Team im nächsten Jahr massiv verbessert, sodass es sowohl Story X als auch Story Y in der Hälfte der ursprünglich benötigten Zeit erledigen kann. Beachten Sie jedoch, dass sich die relative Größe der beiden Stockwerke nicht geändert hat. Aus diesem Grund könnte das Team sie immer noch auf 5 Punkte bzw. 3 Punkte schätzen.
Wenn das Team jedoch seine Fähigkeit zur Durchführung von Story X verbessert, aber seine Fähigkeit zur Durchführung von Story Y nicht verbessert, ändern sich die relativen Größen. Sie könnten vielleicht beide 3-Punkte-Geschichten werden.
Ein Team kann entscheiden, seine Baseline für einen Story Point zurückzusetzen. Der Nachteil dabei ist, dass sie einen gewissen Wert ihrer Geschwindigkeitshistorie verlieren, da sie kein guter Anhaltspunkt mehr für ihre Kapazität für zukünftige Sprints ist. Aber nichts hindert ein Team daran .
Es ist wichtig, sich daran zu erinnern, dass es bei der Geschwindigkeit ausschließlich darum geht, die Kapazität zukünftiger Sprints zu messen. Die Zahlen selbst sind willkürlich, aber die relativen Größen der Zahlen sind wichtig.
Sie haben Recht: Bei Story Points geht es im Wesentlichen um Aufwand. Indem Sie sie als Maß für den Durchsatz Ihres Teams nehmen und bei einem stabilen Team und einer stabilen Umgebung erwarten, dass sich die Geschwindigkeit im Laufe der Zeit stabilisiert und nicht zunimmt (obwohl eine Erhöhung eine Auswirkung eines solchen Prozesses sein könnte).
Bei Story Points geht es nicht um die Komplexität der Entwicklung eines Features; Sie beziehen sich auf den Aufwand, der erforderlich ist, um ein Feature zu entwickeln.
https://www.mountaingoatsoftware.com/blog/its-effort-not-complexity