Cómo manejar el cambio en la historia de referencia

No ajuste nada.

Realmente no importa. Es probable que su historia de calibración/línea de base sea solo de 1 a 3 puntos (como máximo), por lo que la recalibración hará poca diferencia (y nunca vuelva a revisar puntos antiguos, solo aprenda).

¿Por qué estimamos en scrum?

Nosotros estimamos

• Para garantizar que el equipo no aborde demasiado en un sprint (pero también podemos hacerlo a través del recuento de historias)
• Para garantizar que el PO tenga suficiente trabajo listo para el próximo sprint en la planificación (pero la historia vuelve a contar)
• Para permitir que la OP haga una planificación a más largo plazo (pero esto se hace mejor a través de métricas reales como el tiempo de ciclo y el trabajo en curso)
• Para garantizar que el equipo no lleve una historia demasiado grande a un sprint (pero un equipo maduro debería poder medir sin mirar los puntos)

Cualquier otro uso de la velocidad está tratando de volver a la gestión de proyectos de PMO, por lo que está en conflicto con Scrum.

Cualquier velocidad debe ser un promedio, por lo que funcionará por sí sola a largo plazo.

Velocity mide el valor de hacer la historia precisamente de ninguna manera, así que no te preocupes.

Recuerde a Ron Jeffries, quien inventó los puntos de la historia y ahora aboga en contra de ellos.

Scrum no dice exactamente qué metodología usar para determinar cuánto trabajo llevar a un Sprint. Basarlo en la velocidad pasada es una opción, pero hay muchas. Si su equipo se siente cómodo usando la velocidad, considere solo mirar los últimos Sprints. En Programación Extrema, el término es Tiempo de Ayer . Mire la velocidad promedio de los últimos 3 Sprints y utilícelo para planificar su próximo Sprint.

Ahora, ha cambiado sus valores de puntos. Puede traer lo que se siente bien, y en 3 sprints, su velocidad se habrá recalibrado. Asegúrese de concentrarse primero en el trabajo más importante, y tal vez tenga algunos elementos pendientes adicionales refinados y listos en caso de que planifique lo que se trae y esté listo para involucrar al propietario del producto en el curso de acción correcto.

No hay necesidad de pensar demasiado en esto. Estoy seguro de que su equipo tiene un buen presentimiento sobre lo que puede ocurrir en un Sprint. Si se adhiere a las recomendaciones de Scrum, en unas pocas semanas, su velocidad se puede usar nuevamente para planificar un Sprint de manera efectiva.

Estimación y matemática simple.

Sea vOld = velocidad antigua

Sea bOld = esfuerzo de la línea de base anterior

Sea bNew = esfuerzo de la nueva línea de base

Sea vNew = nueva velocidad

Por lo tanto:

vNuevo = vAntiguo * bAntiguo / bNuevo

Tenga en cuenta que si mide en nuevos puntos, bNew = 1. Por lo tanto:

vNuevo = vAntiguo * negrita

Por ejemplo. Digamos que tu antigua velocidad es de 50 puntos/sprint. Supongamos también que su Equipo estima que su antigua historia de referencia vale 2,5 puntos de historia utilizando su nueva definición de puntos. Por lo tanto, su nueva velocidad es 50 * 2,5 = 125 puntos/Sprint.

El truco será estimar con exactitud y precisión la negrita en nuevos puntos. Tenga en cuenta, sin embargo, que suponiendo que las condiciones sean similares (el mismo desarrollador trabajó en ambas historias, sin modificadores obvios del rendimiento como interrupciones, privación del sueño, sin grandes ganancias por la mejora del conocimiento, etc.), entonces esta estimación será relativamente fácil, ya que todos lo que debes hacer es mirar la diferencia entre el tiempo real que tomaron ambas historias. Por ejemplo, si bOld tomó 5 días laborables y bNew tomó 3, entonces bOld es 0.6). Por lo tanto, debe tratar de elegir historias que tengan condiciones tan similares como sea posible.