Wie gehen Sie mit der Änderung in der Ausgangsgeschichte um?

Nichts verstellen.

Es spielt keine Rolle. Ihre Kalibrierungs-/Baseline-Geschichte wird wahrscheinlich nur 1-3 Punkte (höchstens) betragen, so dass eine Neukalibrierung kaum einen Unterschied machen wird (und nie alte Punkte wieder aufgreifen, nur lernen).

Warum schätzen wir in Scrum?

Wir schätzen

• Um sicherzustellen, dass sich das Team in einem Sprint nicht zu viel vornimmt (aber wir können das genauso gut über Story Counts machen)
• Um sicherzustellen, dass der PO gerade genug Arbeit für den nächsten Sprint bei der Planung bereit hat (aber die Geschichte zählt wieder)
• Um dem PO eine längerfristige Planung zu ermöglichen (aber dies geschieht besser über echte Metriken wie Zykluszeit und Wip)
• Um sicherzustellen, dass das Team keine zu große Geschichte in einen Sprint mitnimmt (aber ein ausgereiftes Team sollte in der Lage sein, zu messen, ohne auf Punkte zu schauen)

Jede andere Verwendung von Geschwindigkeit versucht, zum PMO-Projektmanagement zurückzukehren, steht also im Konflikt mit Scrum.

Jede Geschwindigkeit sollte ein Durchschnitt sein, damit sie auf längere Sicht von selbst funktioniert.

Die Geschwindigkeit misst den Wert der Geschichte in keiner Weise, also schwitzen Sie nicht.

Erinnern Sie sich an Ron Jeffries, der Story Points erfunden hat und sich jetzt dagegen ausspricht.

Scrum schweigt sich darüber aus, welche Methodik verwendet werden soll, um zu bestimmen, wie viel Arbeit in einen Sprint eingebracht werden soll. Es ist eine Option, es auf der Geschwindigkeit der Vergangenheit zu basieren, aber es gibt viele. Wenn Ihr Team mit Velocity zufrieden ist, sollten Sie sich nur die letzten paar Sprints ansehen. In Extreme Programming ist der Begriff Wetter von gestern . Sehen Sie sich die durchschnittliche Geschwindigkeit der letzten 3 Sprints an und verwenden Sie diese, um Ihren nächsten Sprint zu planen.

Jetzt haben Sie Ihre Punktwerte geändert. Sie können es bringen, was sich richtig anfühlt, und in 3 Sprints wird sich Ihre Geschwindigkeit neu kalibriert haben. Konzentrieren Sie sich zuerst auf die wichtigste Arbeit und halten Sie vielleicht einige zusätzliche Backlog-Elemente bereit, falls Sie das, was eingebracht wird, unterplanen, und seien Sie bereit, den Product Owner für die richtige Vorgehensweise zu gewinnen.

Es gibt keinen Grund, darüber nachzudenken. Ich bin sicher, Ihr Team hat ein gutes Gefühl dafür, was in einem Sprint alles passieren kann. Wenn Sie sich an die Empfehlungen von Scrum halten, kann Ihre Geschwindigkeit in einigen Wochen wieder genutzt werden, um einen Sprint effektiv zu planen.

Schätzung und einfache Mathematik.

Sei vAlt = alte Geschwindigkeit

Sei bAlt = Aufwand der alten Grundlinie

Sei bNeu = Aufwand der neuen Basislinie

Sei vNeu = neue Geschwindigkeit

Deshalb:

vNeu = vAlt * bAlt / bNeu

Beachten Sie, dass beim Einmessen neuer Punkte bNeu = 1 ist. Daher:

vNeu = vAlt * bAlt

Zum Beispiel. Nehmen wir an, Ihre alte Geschwindigkeit beträgt 50 Punkte/Sprint. Nehmen wir auch an, Ihr Team schätzt Ihre alte Baseline-Story auf 2,5 Story-Punkte, wenn Sie Ihre neue Definition von Punkten verwenden. Somit beträgt Ihre neue Geschwindigkeit 50 * 2,5 = 125 Punkte/Sprint.

Der Trick besteht darin, bOld in neuen Punkten genau und präzise zu schätzen. Beachten Sie jedoch, dass unter der Annahme, dass die Bedingungen ähnlich sind (derselbe Entwickler hat an beiden Geschichten gearbeitet, keine offensichtlichen Leistungsmodifikatoren wie Unterbrechungen, Schlafentzug, kein großer Gewinn durch verbessertes Wissen usw.), diese Schätzung insgesamt relativ einfach sein wird Sie müssen sich nur den Unterschied zwischen der tatsächlichen Zeit ansehen, die beide Geschichten in Anspruch genommen haben. Wenn zum Beispiel bOld 5 Manntage und bNew 3 Manntage in Anspruch genommen hat, dann ist bOld 0,6). Sie sollten daher versuchen, Geschichten auszuwählen, die möglichst ähnliche Bedingungen hatten.