Pregunta : Llevar elementos de un sprint al siguiente
Respuesta : si
Escenario : soy un nuevo scrum master en un equipo y acabamos de completar nuestro primer sprint. No estaba aquí cuando el equipo planeó el sprint, pero planeamos completar 73 Story Points. Calculé que nuestra velocidad es de aproximadamente 53 puntos de historia (Sprints anteriores) y algunos miembros del equipo estuvieron fuera durante diciembre y una persona tuvo un hijo. No estoy seguro de por qué planearon aforo completo con esas personas de permiso.
Task 1 : 8sp - Done
Task 2 : 20sp - WIP
Task 3 : 8sp - Done
Task 4 : 5sp - Testing in Progress
Task 5 : 8sp - WIP
Task 6 : 8sp - WIP
Task 7 : 8sp - Testing Failed
Task 8 : 8sp - WIP
El sprint finaliza mañana y hay un montón de historias para el nuevo sprint. Como mencioné, calculé la velocidad del equipo como 53 sp (Sprints anteriores). Con el trabajo en WIP/Falló la prueba, suma 21 (si la prueba pasa en el elemento de 5 sp). Hacen programación de amigos si alguien está atascado, lo cual es increíble.
En la retrospectiva de sprints actual mencionaré los siguientes:
a. Habilidad cruzada - Necesito trabajar en eso
b. Necesitamos planificar mejor y tener en cuenta las licencias
C. Necesitamos hablar durante el sprint si no vamos a hacer el sprint, entonces podemos hacer los ajustes necesarios
d. Recuérdeles los valores de Scrum.
mi. ¿No podemos hacer las tareas más pequeñas?
¿Tal vez tiene alguna otra sugerencia para mejorar nuestra planificación, elementos comprometidos para alcanzar nuestra velocidad objetivo y estoy en el camino correcto?
Hay mucho allí, así que analicemos elemento por elemento.
Primero, ¿qué hacemos con el trabajo incompleto?
Vuelve a la cartera de productos. Técnicamente, el propietario del producto decide si aún es importante hacerlo en el próximo sprint. Es completamente razonable que digan "No, eso ya no es lo importante, esto es lo otro". Es cierto que la mayoría de las veces serán llevados al siguiente sprint, pero no es un hecho.
A continuación, los puntos parciales de la historia son un antipatrón. Recompensa el comportamiento de no completar el trabajo, lo que va directamente en contra de los principios ágiles (el software de trabajo es la medida principal de progreso, específicamente). Toda la historia está hecha o no.
Velocidad media
Por lo general, calculo la velocidad promedio de la misma manera: elimina los valores atípicos. Si tiene una velocidad bastante constante, también podría usar un promedio mediano en lugar de la media: logra lo mismo básico. Es importante recordar que los puntos de la historia son, por diseño, imprecisos. Cuando aplicamos las matemáticas a cualquier cosa, a veces creamos la ilusión de precisión y debemos estar atentos a eso.
Retrospectivo
Todos estos parecen puntos completamente válidos, pero recuerda que, como scrum masters, no podemos agitar una varita mágica sobre el equipo y mejorarlo. La mejora que el equipo encuentre por sí solo se mantendrá mucho mejor que la que les digas que hagan. Como facilitador de la retrospectiva, ¿puede crear un formato de conversación en el que sea probable que encuentren uno o más de estos por su cuenta?
erik
Ruán
aventura2099