Saltar al contenido

¿Deseas suscribirte al blog y recibir mis últimas actualizaciones? Haz click aquí.

SCRUM: ¿Deberíamos re-estimar user stories casi terminados en el siguiente sprint?

Como parte de mis labores como Scrum Master en mi equipo me he dado a la tarea en las últimas semanas de ir armando un pequeño documento en format de FAQ o de preguntas frecuentes de manera que si alguien, incluso yo, tenemos dudas con parte de la metodología de SCRUM podamos tener respuestas rápidas y sobre todo una justificación de la decisión. A manera de ejercicio estaré publicando tips que creo son interesantes. Una de estas dudas que normalmente saltan es, cuando estimamos una historia que no se terminó en el sprint actual pero está casi terminada ¿Debemos re-estimarla?

La respuesta corta: NO. La historia que no se terminó en el sprint actual debe volver al product backlog o bien moverla al siguiente sprint si aun sigue teniendo la misma prioridad. La razón por la cual no re-estimamos es porque aun cuando la historia casi se completo (por ejemplo, se «atoró» en el review) los puntos de esa historia que no entregamos se agregarían a los del siguiente sprint o en el cual se entregue finalmente la historia lo cual eventualmente permitirá tener un promedio de puntos.

Por ejemplo, si nos comprometimos a 40 puntos en el último sprint pero solo completamos 32 es muy probable que para el siguiente sprint esos 8 puntos restantes se agregarán a ese sprint rápidamente y posteriormente podríamos «meter» otro story de 8 puntos a dicho sprint desde el product backlog o uno de 5 y otro de 3, etc. El punto es que ne el sprint 1 completamos 32 puntos, y en el segundo completamos 48 puntos así que ese aumento o «pico» en los charts nos dirá fácilmente que alguna o varias de esas historias se completaron en el siguiente sprint porque ya casi estaban terminadas en el anterior.

Dicho eso, digamos que tenemos este comportamiento consecutivamente en 4 sprints:

SCRUM Velocity Chart
SCRUM Velocity Chart

Como podemos ver hay un patrón de un sprint donde nos hemos comprometido a más de lo que cumplimos y posteriormente, ya que movimos los stories casi completados, el trabajo entregado de se sprint siguiente fue mas alto que a lo que nos comprometimos lo cual es aceptable. Lo importante es que tomemos estos números para obtener una «Velocidad promedio» del equipo que en este caso serían 38 puntos.

Utilizando esta técnica y según pasan mas sprints iremos obteniendo un mejor resultado de puntos promedio para establecer la velocidad del equipo. Si re-estimaramos las historias que no se terminaron en el sprint pasado y les dieramos por ejemplo una puntuación mas baja entonces tendríamos sprints subsecuentes con menos puntos, digamos que ese story de 8 puntos y otros que pasamos a los siguientes sprints los re-estimamos con una puntuación de 1 o 2 porque estan «ya casi listos»:

SCRUM Velocity Chart
SCRUM Velocity Chart

A simple vista se ve que en los 4 sprints nos hemos comprometido a más de lo que hemos entregado, pero no solo eso, hemos entregado mucho menos trabajo del que realmente realizamos, es decir, la gráfica no representa el esfuerzo que realmente dedicó el equipo. Es por esta razón que una vez estimados y trabajados los stories no deberíamos re-estimarlos sino solo moverlos de sprint para que ese esfuerzo que no se representó en el actual sprint se propague al siguiente.

Publicado enIngeniería De Software

Un comentario

  1. Ana Karina Ana Karina

    Si movemos esas historias no re estimadas el tablero no muestra la realidad de los puntos a realizar en este sprint.
    Entonces debería re estimar esas historias que no se terminaron para reconocer a simple vista el verdadero velocity del sprint en curso.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.