Wir haben vor kurzem damit begonnen, Story Points in unserem agilen Prozess zu verwenden, was großartig ist. Aus diesem Grund erhalten wir Schätzungen für bestimmte Aufgaben und bekommen eine Vorstellung von unserer Geschwindigkeit.
Ich bin jedoch neugierig, ob Story Points jemals zur Messung des Wachstums des Teams verwendet werden können oder sollten?
Nehmen wir für das klassische Beispiel an, wir haben eine Gruppe von Entwicklern, die sich einig sind, dass ein Problem oder Projekt 21 Story Points wert ist. Bei einigen Entwicklern dauert es 3 Tage, bei den anderen Entwicklern 6 Tage.
Irgendwann, bei gleich bleibender Komplexität der Themen, steigt natürlich die Produktivität der Entwickler aufgrund ihrer Vertrautheit mit der Codebasis usw. Gibt es eine effektive Möglichkeit, das Wachstum im Team mit Story Points zu messen? Oder vielleicht ist dies der völlig falsche Weg.
Geschwindigkeit misst die Menge an Aufwand, die das Team im Durchschnitt in einem bestimmten Sprint aufbringen kann. Dafür kann es viele Gründe geben. Es könnte sein, dass das Team in seinen technischen Fähigkeiten gewachsen ist. Es könnte sein, dass das Team besser zusammenarbeitet, weil es den letzten Teil der Forming-, Storming-, Norming-, Performing-Phase erreicht hat. Es könnte sein, dass organisatorische Hindernisse beseitigt wurden, wodurch der Weg für das Team geebnet wurde, effizienter zu werden. Es könnte auch sein, dass das Team durch den häufigen Inspektions- und Anpassungsprozess in den Sprint-Retrospektiven Teambarrieren für eine gesteigerte Produktivität beseitigt hat.
Wenn die Geschwindigkeit zunimmt, wird theoretisch mehr Wert live an die Benutzer weitergegeben.
Unabhängig von den genauen Umständen, die zu der Geschwindigkeitszunahme geführt haben, scheint es, als hätte eine Form von Wachstum stattgefunden. Sie könnten Geschwindigkeit verwenden, um zu zeigen, dass ein Team „gewachsen“ ist, aber es scheint nicht klar zu sein, wie Sie genau sagen können, welcher Teil des Teams gewachsen ist.
Darüber hinaus könnte der Versuch, genaue Details zu verstehen, zu Problemen bei der Selbstorganisation und Selbstverantwortung führen, wenn die Person, die versucht, die Messung durchzuführen, ein Manager oder eine Person in einer Autoritätsposition ist. Es könnte dazu führen, dass das Team dem Manager nachgibt oder denkt, dass es etwas falsch macht, oder es könnte dazu führen, dass es aufhört zu experimentieren und weitermacht, was immer ein Manager oder eine Autoritätsperson als einzigen Grund für Wachstum identifiziert hat (selbst wenn es war nicht der einzige Grund).
Wenn das Team schließlich feststellt, dass sich ein Manager oder eine Autoritätsperson auf ihre Velocity konzentriert, können sie versuchen, diese Metrik zu spielen. Wenn wir darüber hinaus höheren Managern Geschwindigkeit zeigen und die Machthaber dann aus irgendeinem Grund einen Geschwindigkeitsabfall beobachten, stören sie das Team möglicherweise eher, als wenn sie dieser Metrik überhaupt nie ausgesetzt gewesen wären. Einige zertifizierte Scrum-Trainer, wie Michael James, Schöpfer der Scrum-Trainingsreihe , schlagen vor, dass die Geschwindigkeit stattdessen am besten für die Veröffentlichungsprognose verwendet wird, um zu zeigen, wie viele Funktionen in einem Zeitraum von 3 bis 6 Monaten oder irgendwann in der Zukunft veröffentlicht werden könnten. Dies führt mit geringerer Wahrscheinlichkeit zu den oben aufgeführten Problemen, da ein guter Product Owner einen Release-Plan erstellen könnte, der auf einem Bereich statt auf exakten Messungen basiert.
Aug
jmort253
Kronax