¿Deberías volver a estimar las historias de los usuarios?

Mi proyecto actual está teniendo una 'discusión' que se divide por la mitad: "esta historia es más compleja de lo que pensábamos originalmente, deberíamos volver a estimar" vs ", nunca debes volver a estimar, ya que solo estimas hacia arriba y nunca hacia abajo " .

¿Alguien puede arrojar algo de luz sobre si alguna vez debe volver a estimar?

En mi humilde opinión, me imagino que podría traer una tarjeta completamente nueva para un nuevo requisito o historia, pero volver atrás y volver a estimar los elementos de la cartera parece distorsionar el concepto de tamaño relativo y solo 'inflará' su cartera de pedidos.

Una parte central de la estimación de historias en un equipo en el que trabajé fue la idea de una historia que era "demasiado grande" para estimar. Es decir, la carga de trabajo implícita en la historia estaba más allá del alcance de un solo sprint.

A medida que llegaba más información, o el equipo comprendía mejor lo que al principio parecía una sola bestia de una historia, a menudo volvíamos a estimar la historia. En la mayoría de los casos, esto podría implicar dividir la historia "demasiado grande" en historias más pequeñas y alcanzables y estimarlas.

Estas historias `` demasiado grandes '' nunca entraron en números de tamaño ni en gráficos quemados.

Además, podríamos volver a una historia en el futuro y con una mejor comprensión de los requisitos, podríamos volver a estimar. No debe volver a estimar una historia simplemente porque se ha vuelto más fácil de lograr (por ejemplo, después de construir un montón de bibliotecas de marcos, un trabajo dependiente será más fácil de lograr), porque la idea es que a medida que se convierte en ' mejor ', el equipo puede lograr más en un sprint, pero ciertamente creo que es válido volver a estimar las historias si su comprensión de ellas cambia.

Lo siguiente iba a ser un comentario, pero me dejé llevar ...

No olvide distinguir entre tamaño y complejidad en su estimación. Debe estimar solo el tamaño, no la complejidad o la dificultad. Por ejemplo, agregar un botón a una pantalla siempre debe ser un '1', ya que, en lo que respecta al usuario, obtiene un botón, el tamaño es muy bajo. No importa si realmente lo implementa en C # (baja complejidad, muy fácil) o ensamblado (alta complejidad, muy difícil); La historia del usuario tiene el mismo tamaño.

Por lo tanto, cuando digo que vale la pena volver a estimar cuando los cambios de comprensión, no es que su comprensión de cómo implementar la característica ha cambiado, es su comprensión de lo que la función es lo que ha cambiado.

Entonces, "Quiero un botón" es fácil, pero luego te das cuenta de que el usuario quiere decir "Quiero un botón en el que se pueda hacer clic, que se vuelve verde y le muestra un mensaje , ahora es una historia más compleja, por lo que debería volver a aparecer estimado.

Actualización ; según lo solicitado, trataré de elaborar lo que quiero decir al estimar el "tamaño" en lugar de la complejidad.

Creo que es más fácil considerar esta distinción en términos de un nuevo producto. Su equipo tiene la tarea de construir un sistema de pantallas múltiples, donde todo es nuevo. Entre sus historias de usuario, tiene una serie de historias como;

1) Quiero un botón en la pantalla A, que al hacer clic mostrará un error a usuarios no autorizados. 2) Quiero un botón en la pantalla B, que al hacer clic mostrará un mensaje si el día actual es un fin de semana. 3) Quiero una opción de menú en la pantalla C, que al hacer clic hará que la pantalla parpadee cada 5 minutos.

Ahora, cuando el equipo estima estas historias, acuerdan que todas tienen aproximadamente el mismo tamaño, y estiman cada una como una historia 'pequeña', con un valor de 5 puntos en su escala de velocidad de sprint.

Los sprints comienzan, y para el primer sprint, el equipo no logra ninguna de estas historias, porque pasan todo el ciclo creando proyectos, infraestructura, bibliotecas centrales, etc. Y hay un nuevo tipo en el equipo que todavía está aprendiendo.

Unos pocos sprints y el equipo arma una pantalla que completa la historia # 1: días felices, ahora han alcanzado 5 puntos de velocidad. (Con un promedio de decir, 1 punto por sprint, debido a los sprints improductivos al comienzo).

Ahora, para el próximo sprint, la infraestructura está en su lugar, el equipo tiene una plantilla de pantalla para reutilizar y el nuevo tipo está entendiendo las cosas, y este sprint, el equipo elimina la historia # 2 y # 3.

Ahora, han logrado 10 puntos en un sprint, para un promedio de aproximadamente 4 puntos por sprint. Esto muestra que la productividad del equipo está mejorando con el tiempo, lo cual es completamente esperado, a medida que el proyecto evoluciona, las habilidades del equipo mejoran, el código central se reutiliza (no se reescribe).

Esto para mí es el ideal. Historias bien estimadas, que demuestran un aumento de la velocidad en el tiempo (que, eventualmente, se estabilizaría, a menos que cambie algo importante, como un nuevo miembro del equipo, etc.).

Por otro lado, si desde el principio, el equipo analizó esas historias y las estimó en función de la complejidad, encontrarían que la Historia # 1 es una historia GRANDE, ya que están tomando en cuenta todo el esfuerzo de aceleración, más el chico nuevo que necesita entrenamiento. La historia n. ° 2 es MEDIA, porque creen que al menos estarán en camino para entonces, y debería ser más fácil. Y finalmente, la historia # 3 es PEQUEÑA, porque será fácil una vez que se terminen # 1 y # 2.

Ahora, lo que ha terminado en este modelo es simplemente una estimación ofuscada de TIEMPO; las estimaciones tienen en cuenta lo difícil que será y cuánto tiempo llevará hacer un trabajo, y como sabemos, esto es difícil en el mejor de los casos. En este modelo, la velocidad se iguala desde el principio, y nunca podrá demostrar una mejora en el rendimiento del equipo. Si calcula a tiempo, solo podrá lograr 40 horas de trabajo en una semana. Y sería una tontería planificar un sprint con más o menos trabajo. Si el equipo mejora sus capacidades, solo puede reservar 40 horas de trabajo. Solo lograrás 40 horas de trabajo.

Por lo tanto, por qué noté que un trabajo en C # es más fácil que un trabajo en Asamblea (menos complejidad), pero que el "tamaño" de la tarea debe estimarse de manera equivalente. De esa manera, puede ver que la elección de mover idiomas, las mejoras en la capacidad (o los ajustes a alguna otra dinámica de equipo) tienen un impacto directo en la velocidad.

[ Otra actualización: priorización de direccionamiento ]

En cuanto a la priorización, creo que esta es una discusión separada para dimensionar / estimar. No prioriza la cola simplemente en las estimaciones de una historia, de lo contrario, solo haríamos trabajos pequeños, y nunca los más grandes, [posiblemente] más importantes. En un equipo que dirigí, teníamos conversaciones rutinarias sobre la complejidad al administrar una cola de sprint. La orden de compra se daría a entender que, si bien alguna tarea es una tarea "PEQUEÑA" (en puntos de la historia), puede ser difícil de lograr debido a X, Y, Z. A veces, la velocidad del equipo se vería afectada, para implementar algunas de estas historias más complejas. Otras veces, el PO diría "bueno, preferiría tener otras 5 cosas más este sprint, así que pospondremos los trabajos más complejos".

Si simplemente estimáramos historias en dificultad, eso estaría ocultando la velocidad. Las tareas difíciles o que consumen mucho tiempo siempre recibirían más ponderación, para que la velocidad sea promedio. Como señalé antes, esta es solo una forma diferente de estimar el tiempo, y no hay velocidad de seguimiento de puntos si este es su método de estimación, ya que siempre tiene una duración fija para un sprint, por lo que su "velocidad" solo cambiaría si usted estimado incorrectamente (p. ej., una tarea de 8 horas tomó 1 hora).

¿Espero que eso lo aclare un poco?

La razón principal que no menciono es que destruye la utilidad de tu velocidad. Considere un equipo de scrum hipotético que estima cada historia como 1 punto. Completan aproximadamente 10 historias cada iteración, para una velocidad promedio de 10.

Durante una retrospectiva, un miembro del equipo argumenta que, en retrospectiva, cuando repasas casi todas las iteraciones, una de las historias realmente debería haber sido un puntero de 5, por lo que deberían señalarla para "arreglar" su velocidad. Eso eleva su velocidad a 14.

La próxima planificación, la velocidad sugiere que pueden asumir cuatro historias más. Están bastante seguros de que no puede ser correcto, porque hay muchas posibilidades de que una de las historias futuras que estimaron sea realmente un puntero de 5. Desafortunadamente, no tienen idea de cuál. De repente, tienen una cifra de velocidad que es absolutamente inútil para la planificación.

La cuestión es que, si hubieran mantenido su velocidad a 10, eso tiene en cuenta sus habilidades de estimación. Si el 10% de sus historias en iteraciones anteriores fueron realmente 5 punteros, entonces las probabilidades son el 10% de sus historias en iteraciones futuras se subestiman de manera similar. Durante un largo período de tiempo, todo sale en el lavado.

Recuerde que la velocidad no tiene unidades. Un número más alto no es mejor que uno preciso y útil. Si desea alardear, simplemente multiplique todo por 1000 :-)

Respuesta corta: el propietario del producto puede hacer cualquier cosa que quiera para una historia, hasta el sprint donde el equipo se compromete a completarla.

Entonces, si el equipo quiere volver a estimar una historia para un futuro sprint, enloquece.

Una vez que estás en el sprint, el trabajo (y la estimación) es fijo.

He trabajado de esta manera en numerosos proyectos y funciona bien. Si está quemando el trabajo atrasado del producto, asegúrese de actualizar la estimación o al menos de manera visual dejar en claro que el cambio no es un caso de quemado.

Parece que en este caso, si la estimación fuera muy errónea, cancelaría el sprint y comenzaría de nuevo. Esto, por supuesto, dependería del scrum master y del propietario. Cuando no hay forma de cumplir con un presupuesto cercano, debemos ser honestos con el jefe y decirles lo antes posible para que se puedan tomar decisiones.

No hay ningún problema para volver a estimar los elementos acumulados, hacia arriba o hacia abajo. El desarrollo es un proceso de aprendizaje, por lo que se espera que algunos elementos de la cartera de pedidos futuros se vuelvan más simples o más complejos dependiendo del conocimiento adquirido en sprints anteriores.

Tal vez la 'velocidad' (si el equipo / empresa la usa como métrica) no podría medirse exactamente en caso de una gran reestimación, pero lo más importante es que los ejercicios de reestimación afinarían las propias estimaciones del equipo en futuro. La clave para ser predecible es utilizar la mayor cantidad de información actualizada, no restringida a una estimación temprana.