Dies ist eine ausgezeichnete Frage, und es ist sehr wichtig, dass sich die Teams verbessern. Das Thema täuscht und wird weitgehend missverstanden. Der ursprüngliche Zweck des Story-Pointings bestand darin, eine schnelle und akzeptabel genaue Methode zur Schätzung des Aufwands (Level of Effort, LOE) zu finden, der zur Vervollständigung der in Storys definierten Funktionen erforderlich ist. Das übergeordnete Ziel: Geben Sie den Teams eine Methode zur PROGNOSE oder Vorhersage, wie lange es dauern würde, eine Anstrengung (z. B. ein Projekt) abzuschließen. Dein Verständnis von Velocity ist richtig: Es werden die DURCHSCHNITTSPUNKTE pro Sprint abgeschlossen (wirklich FERTIG). Wenn Sie also ein Projekt liefern müssen und es 250 Punkte hat und Ihr Team durchschnittlich 25 Punkte pro Sprint erzielt, dauert das Projekt ungefähr 10 Sprints plus oder minus einer Pufferzeit.
Einige Leuchten wie Ken Schwaber schlagen vor, Geschwindigkeit und Punkte nur für mittel- bis langfristige Vorhersagen zu verwenden. Sie schlagen vor, die Arbeitsstunden als zweiten "Sanity Check" zu verwenden, um festzustellen, was in einem Sprint tatsächlich möglich ist. Die Anzahl der Punkte in jedem Sprint kann also je nach Kapazität variieren. Andere (einschließlich ich) glauben, dass sich ein ausgereiftes Team auf ein sehr konsistentes Größenmuster einlassen wird, mit dem die Kapazität genau vorhergesagt werden kann, und dass die Arbeitsstunden schließlich zu einer nutzlosen zusätzlichen Belastung werden. (Es ist wichtig, dass neue Teams mindestens 6 bis 12 Sprints absolvieren, bis das Team die Punkte und die Größe der Story richtig verstanden hat.)
Ihr erster kleiner Fehler ist, dass Sie sagten, das Team sollte die Geschwindigkeit kennen und so viele Story-Punkte einbringen. Tatsächlich ermutigen Trainer die Teams, 10% bis 20% abzuziehen und sich stattdessen * auf dieses Niveau zu verpflichten. Wenn Ihr Team also tendenziell 25 Punkte pro Sprint erreicht, füllen Sie den Sprint nicht auf 25 Punkte auf, sondern halten Sie bei 20 bis 22 Punkten an. Denken Sie daran: Es ist in Ordnung, Geschichten einzubringen, wenn die andere Arbeit erledigt ist. Sie können sich also auf 22 Punkte festlegen und 28 Punkte vervollständigen. Das ist großartig. Seien Sie einfach vorsichtig und ermutigen Sie das Team nicht, Sandsack zu machen und sich ständig zu engagieren. Es ist nichts Falsches daran, sich zu strecken, um zu sehen, ob wir mehr können.
Nun zu Ihrem Punkt über die Varianz zwischen Sprints. Es ist ein weit verbreitetes (aber NICHT OPTIMALES) Muster, ein Team zu sehen, das 20 Punkte bei einem Sprint, dann 50, dann 22, dann 45, dann 15 und dann 60 erreicht. Wenn Sie die Abweichung berechnen, können Schwankungen von 50% auftreten. zu 100% sprint nach sprint. Warum erreichen Teams in einem Sprint nur 15 Punkte und im nächsten 60?
Es könnte bedeuten, dass das Team wirklich nicht weiß, was es tun kann. (Hey, wir haben im letzten Sprint 50 Punkte geschafft, wir können es in diesem Sprint wieder tun).
ODER, es könnte darauf hindeuten, dass die Produktbesitzer das Team zu einer Überbeanspruchung zwingen oder nach dem Start des Sprints Arbeit hinzufügen. Dies sind nur einige der ANTI-MUSTER, die diesen wilden Schwung in den abgeschlossenen Punkten verursachen könnten.
Diese Vorhersagbarkeitsmaßnahme ist für Scrum-Meister wichtig, um sie zu beobachten und das Team darauf aufmerksam zu machen.
Oft ist der Grund, warum sie in einem Sprint nur wenige Punkte und im nächsten Sprint viele Punkte erreicht haben, das, was ich als "ROLLING WAVE OF INCOMPLETE WORK" bezeichne. Hier ist ein sehr häufiges Muster:
Der Produktbesitzer steht unter dem Druck, einen Termin einzuhalten. Das Team hat also das Bedürfnis zu versuchen, eine Menge Arbeit zu erledigen. Sie beginnen als neues Team und sind sich nicht sicher, was sie tatsächlich erreichen können.
Also Sprint 1, sie planen den Sprint und können, da sie sich in der Formierungsphase befinden, nicht alle Arbeiten abschließen. In der Tat haben sie mehr unvollständige Arbeit als erledigte Arbeit. Die unvollständige Arbeit ist begonnen, aber unvollständig. Es wird zum nächsten Sprint verschoben, und diesmal haben sie mehr als unvollständige Arbeit geleistet. Beim nächsten Sprint fällt diese große Ladung unvollständiger Arbeit auf FERTIG und das Vertrauen des Teams steigt.
Der Produktbesitzer ist aufgeregt und erhöht seine Belastung erneut. Am Ende dieses Sprints haben sie eine RIESIGE Menge unvollständiger Arbeit und eine enttäuschende Menge erledigter Arbeit.
Hier sehen Sie die WAVES of Done vs Incomplete-Wechselsprint nach dem anderen. Wenn Teams nicht wissen, was passiert, kann dieses Muster noch Monate andauern. Im Durchschnitt erreichen sie jedoch rund 24 Punkte pro Sprint. Was passiert also, wenn sie mit der Überbindung aufhören?
Sie werden feststellen, dass sie immer noch 24 bis 26 Punkte erreichen, aber die Verschleppungsarbeit ist reduziert. Anstatt überfordert zu sein und zu versuchen, eine unmögliche Menge an Arbeit zu erledigen, die auch die Moral des Teams zerstört, kann das Team beginnen, seine Prozesse zu verbessern.
Im Laufe der Zeit wird die Geschwindigkeit zunehmen, ohne die großen Schwankungen bei Done-vs-Incomplete-Arbeiten.
Wenn Sie dem Team keine "Nachspielzeit" einräumen, haben sie NIEMALS Zeit für Arbeiten, die sie schlanker, schneller und besser machen. Dev-Ops zum Beispiel können nicht passieren. Testautomatisierung - Wer hat die Zeit dafür? Aber genau an diesen Dingen müssen Teams arbeiten, um die Geschwindigkeit zu erhöhen.