¿Cambian los tamaños de Story Point para tareas repetitivas después de automatizar la tarea?

Aquí está la situación de Scrum:

1. Una tarea determinada (implementar una tabla de datos poblada de back-end) es una historia frecuente
2. Las tablas frecuentemente tienen una funcionalidad similar pero personalizada
3. Cada mesa tarda aproximadamente una semana en implementarse (8 puntos de historia)
4. Finalmente, el equipo invierte 4 semanas para crear un componente reutilizable
5. Ahora crear una nueva tabla es casi instantáneo

Mi pregunta: ¿una nueva historia de tabla sigue siendo un 8 porque la salida / complejidad no ha cambiado? ¿O es un 1 porque el esfuerzo es mínimo?

Mi investigación: cuando tomé el entrenamiento de scrum con Jeff Sutherland, me fui con el entendimiento de que la historia todavía es un 8 porque los puntos de la historia miden la producción. El PM sigue obteniendo las mismas tablas, solo se entregan 5 veces más rápido. Es una mejora de velocidad genuina (haciendo el mismo trabajo pero más rápido)

Pero me gustaría verificar que mi comprensión es correcta. ¿Alguna ayuda por ahí? Estamos buscando la definición formal de scrum, por cierto. Investigué el sitio de scrum inc y revisé "El arte de hacer dos veces el trabajo en la mitad del tiempo" y no puedo encontrar documentación de que mi comprensión sea correcta o incorrecta.

¡Gracias!

Actualización Realmente estaba buscando enlaces a la documentación por parte de las autoridades formales de scrum. Creo que esta pregunta es engañosa ahora porque muchas de las respuestas a continuación son solo opiniones de la gente.

ACTUALIZACIÓN 1/22: RESPUESTA SCRUM INC

"Sigue siendo el mismo para representar la entrega de igual valor. La velocidad del equipo es una medida clave. La mejora de su proceso debería resultar en una mayor velocidad: https://www.scruminc.com/velocity/ " --- Respuesta de Scrum Inc. vía Twitter

MI RESPUESTA CORTA:

El Dr. Jeff Sutherland, el creador de Scrum responde esta pregunta directamente en su seminario web Puntos vs. Horas en la diapositiva 6

¿Qué son los puntos? Los puntos son una medida de la SALIDA del equipo. Correlacionado pero no necesariamente igual al esfuerzo.

JJ Sutherland, CEO de Scrum Inc., lo responde aún más directamente en su lección sobre Acelerar correctamente

Solo porque el equipo ha mejorado en la implementación de una historia dada, el valor en puntos debe ser el mismo.

MI LARGA RESPUESTA

Fuentes Adicionales Como esta pregunta es controvertida, aquí hay una investigación que responde a algunas de las preocupaciones expresadas en otras respuestas:

Si. El objetivo de Scrum es aumentar la velocidad

Fuente 1

Aunque la velocidad tiende a oscilar con el tiempo, como regla general, debería tener una tendencia al alza de alrededor del 10% por Sprint. - JJ Sutherland

Fuente 2

La diapositiva 5 de la Lección de velocidad de Scrum Inc muestra un gráfico de velocidad con una mejora de 12x con el tiempo Y titula el gráfico "Mejora de salida" con "Puntos" como eje y:

Fuente 3

Vaya a ScrumLab.scruminc.com y mire los seminarios web sobre métricas. Muestra cómo medimos el rendimiento de la empresa utilizando la mejora en la velocidad, la métrica de felicidad y los ingresos por punto. Escuché a muchos equipos lentos quejarse de que ir más rápido solo generará más basura. Esto se debe a que los propietarios de productos no son responsables de duplicar los ingresos por punto. Si duplica la velocidad y el doble de ingresos por punto, la compañía generará cuatro veces más dinero. Esto hará felices a todos. Por eso necesitas las tres métricas. - Jeff Sutherland

Si. Puntos de historia Medida Salida / Producción

Fuente 1

La métrica de gestión para la entrega del proyecto debe ser una unidad de producción Jeff Sutherland en su artículo definitivo Por qué los puntos de historia son mejores que las horas

Fuente 2

Si el equipo comienza a estimar historias a valores más bajos porque han incurrido en mucha más experiencia y las historias parecen más fáciles, Velocity nunca parecerá mejorar. Esta es una gran razón por la cual estimar en horas no funciona. - Scrum Inc CEO, JJ Sutherland

NO. El aumento de la velocidad no arruina la previsibilidad

En primer lugar, como PO o ejecutiva la previsibilidad es muy importante, pero la productividad es aún más importante. La mayoría de las OP si tienen la opción de mantener los niveles de producción o mejorar significativamente la productividad a expensas de una pequeña previsibilidad elegirían el aumento de la productividad. Dicho esto, la compensación es una elección falsa si un equipo emplea el patrón de scrum de Yesorrow's Weather recomendado para la planificación del sprint.

Usando el sentido común ... si un equipo produce 10 widgets a la semana, entonces encuentra la manera de producir 40 widgets a la semana; su velocidad ha mejorado 4x. El PO obtiene 4 veces más widgets en la misma cantidad de tiempo. Llamar a esa velocidad plana es contrario a la definición de la palabra.

SI. Jugar al sistema es posible si todo el equipo engaña

Finalmente, es posible jugar el sistema, pero es posible jugar cualquier sistema. Scrum minimiza las historias de selección de cerezas de los desarrolladores individuales extrayendo de una cartera de pedidos ordenada y midiendo la velocidad en equipo, no en base a un desarrollo individual. Si mides dev por velocidad de desarrollo no estás haciendo scrum. Y mitiga los juegos del sistema a través de estimaciones al preparar las historias como grupo. Para hacer una bolsa de arena con sus estimaciones, debe hacerlo frente al grupo y el grupo debe coludir con usted. Pero si quieres jugar con el sistema, realmente no importa qué proceso uses. Scrum depende de un equipo de 4-6 empleados motivados y capaces interesados ​​en lograr objetivos juntos; pero si tiene empleados que hacen trampa en el trabajo para jugar el sistema, entonces su proceso no es el problema.

Sus historias de la mesa de fondo ya no requieren ocho puntos de esfuerzo.

"Un Story Point es una unidad de medida relativa, decidida y utilizada por equipos Scrum individuales, para proporcionar estimaciones relativas de esfuerzo para completar los requisitos"

scrum.org

Si continúa estimando historias de la mesa de back-end en ocho puntos, entonces sesgará su velocidad como una medida del esfuerzo por sprint.

También sería falso seguir asignando ocho puntos al trabajo que usted sabe que solo requieren un punto de esfuerzo.

El aumento de la velocidad no es un objetivo. El objetivo es una planificación confiable.

Los puntos de historia son una herramienta en un ciclo de retroalimentación que le indicará, con el tiempo, cuál es su velocidad típica. Esto le dirá cuántos puntos puede adoptar de manera realista en un sprint. La velocidad puede variar un poco con el tiempo, pero si cambia demasiado rápido, es inútil. Un aumento repentino en la velocidad solo le dirá que aún no sabe lo que está haciendo. Por lo tanto, desea mantener su velocidad constante, eso le dice que sus estimaciones han sido buenas y que probablemente serán buenas para el próximo sprint.

Usted sabe que su salida no es constante, que son conscientes del hecho de que puede crear tablas mucho más rápido ahora. Por lo tanto, sería totalmente contrario al propósito de su ciclo de planificación si insiste en vincular los puntos de la historia con los entregables.

Una vez más, la velocidad no está relacionada con la productividad y un aumento de la velocidad no es motivo para celebrar. Un punto de la historia es, en última instancia, una parte de tu carrera. Para hacerlo más real, algunos equipos definen una tarea bien conocida que todos entienden y la llaman tarea estándar de punto de historia para que cualquier trabajo pueda relacionarse con la tarea estándar en términos de complejidad y consumo de tiempo. No es necesario decir que si la tarea estándar se vuelve más fácil, todo cambiará y todos tendrán que adaptarse al nuevo significado de un punto de la historia, lo que apesta. La manera correcta y conveniente de hacerlo sería definir una nueva tarea estándar que sea igualmente desafiante para el equipo.

Los puntos de la historia reflejan cuánto esfuerzo tomará implementar la historia. Son una predicción de esfuerzo. Si la cantidad de esfuerzo disminuye, también debería hacerlo el número de puntos.

Recuerde, los puntos son una herramienta para ayudarlo a estimar. Nada más y nada menos. No son una recompensa o una métrica que mide la producción. Son simplemente una forma de estimar cuánto trabajo se necesitará para lograr el objetivo de la historia.

Usted dice que esta tarea originalmente tomó 8 puntos, lo que equivale a aproximadamente una semana. Ahora digamos que tus sprints duran una semana, así que en la planificación vas a obtener 8 puntos de historias. Si mantienes esta historia en 8 puntos, entonces solo puedes planear terminar esta historia en el sprint. Si el tiempo real es solo una hora en lugar de 40 horas, ¿qué vas a hacer con las otras 39 horas? Acaba de crear un plan muy pobre para su sprint debido a puntos de historia inexactos.

Si la historia se representa con mayor precisión como un punto, eso significa que aún puede obtener 7 puntos más en el sprint actual de una semana. Eso parece reflejar más de cerca tu realidad, por lo que cambiar el tamaño de la historia tiene sentido porque te ayuda a planificar.

Menciona en su pregunta el deseo de mejorar la velocidad, pero eso no es realmente lo que debería estar haciendo. Al menos, no en el sentido literal. Su productividad aumentará naturalmente, pero en aras de la planificación, su valor de velocidad debe permanecer bastante constante.

Piensa en los efectos. Digamos que tiene un equipo de cinco, una velocidad de 100 puntos en un sprint y razonablemente espera que todos manejen 20 puntos. Ahora tiene esta tarea que se ha vuelto trivial, pero que aún obtiene ocho puntos. Un miembro del equipo toma cinco de estas tareas, las realiza en dos días, pone los pies sobre el escritorio durante los ocho días restantes, supera a todos al manejar 40 puntos de tareas y obtiene una bonificación. El jefe mastica a todos los demás.

Si está satisfecho con eso, no cambie los puntos para esta tarea. No me gustaría esa situación.

Se debe esperar que cada tarea con el mismo número de puntos le tome al desarrollador la misma cantidad de tiempo.

Y estoy totalmente, totalmente en desacuerdo con la respuesta de Nathaniel aquí. Mantener los puntos hará que la velocidad sea totalmente impredecible, porque algunas tareas se realizarán más rápido, pero otras no, por lo que un sprint con tareas aceleradas te dará una gran velocidad, y el siguiente sprint volverá a bajar.

Tampoco es como lo estimarías. Si sé que tengo diez tareas bastante similares, no les doy los mismos puntos en primer lugar. Doy muchos puntos al primero, destinados a "hacer las tareas y construir las herramientas para hacer tareas similares muy rápidamente", y luego muchos menos puntos a las tareas repetidas.

Es una situación diferente cuando un desarrollador junior comienza, o un desarrollador se une a un equipo diferente, y aumenta su velocidad en otro momento porque aprenden (cómo hacer su trabajo en primer lugar, o todos los bits que necesitan saber sobre el particular proyecto).