¿Qué hacer cuando un sprint termina temprano?

¿Qué hacer cuando un sprint termina temprano?

Por el momento, nuestro equipo Scrum trabaja con historias de la cartera de pedidos, si el sprint se termina temprano.

¿Qué sucede con las historias tomadas de la cartera de pedidos? ¿Se agregarán las historias al Sprint actual? En caso afirmativo, ¿qué pasa si estas historias no se terminarán a tiempo? ¿El Sprint falló entonces?

Trae algo del backlog del proyecto al sprint (después de las discusiones con scrum master y el propietario del proyecto).

El tamaño del artículo que realice dependerá de cuánto tiempo tenga. Si no hay nada lo suficientemente pequeño, cree una subtarea de una tarea más grande para comenzar (es decir, realice parte del trabajo preliminar).

Alternativamente, cree algunas tareas que mejoren la base del código. Nunca he visto una base de código que no pueda mejorarse de alguna manera. Revise algunos códigos, agregue más pruebas unitarias, etc.

Trabajar en artículos de reserva de sprint de estiramiento o futuros parece ser lo más común, lo que tiene mucho sentido si sus artículos de reserva de sprint son lo suficientemente pequeños y claramente definidos. Sin embargo, deben evitarse los elementos acumulados que pueden colocar el código "hecho" en un estado "no terminado".

Si el sprint está realmente terminado, etiquételo, prepárelo para la entrega, entrégalo y coloque sus repositorios de código fuente en el estado "siguiente sprint" para que no haya riesgo de que los cambios de sprint tardíos pongan en riesgo la entrega.

Para nosotros, un Sprint nunca termina temprano. Solo aumentamos nuestra velocidad o resolvimos el problema de una manera que nos hace hacer más trabajo en el sprint.

Diciendo que siempre tenemos una acumulación de artículos que nuestros propietarios de productos priorizan en orden de importancia. Cuando cualquier equipo puede realizar más trabajo en el sprint, es muy fácil para ellos ver qué hacer a continuación en la lista que se ajuste positivamente al tiempo restante de los sprints dada su velocidad.

Esto evita cualquier tiempo de inactividad por parte del grupo que espera discusiones con el propietario del producto / Scrum Master sobre lo que se debe hacer a continuación. Nuestros propietarios de productos y Scrum Masters se mantienen al tope de esta lista, por lo que siempre hay más trabajo esperando para ser puesto en el próximo sprint (o el actual si el tiempo lo permite)

Lo que hace mi equipo es extraer tareas de la cartera de pedidos que son lo suficientemente pequeñas como para completarlas con respecto a lo temprano que terminamos. Si hemos terminado con eso , le damos a nuestro equipo de control de calidad tiempo para ponerse al día con sus pruebas, y los desarrolladores obtienen un "día libre". Podemos usar esto para buscar otros problemas no relacionados con el sprint actual, temas que queremos para investigar, configurar / reconfigurar nuestros entornos, etc.

No pongas una tonelada de trabajo solo porque hayas terminado temprano. Apégate a lo que tu equipo se ha comprometido a hacer en este sprint, y si se termina el trabajo extra, es una gran ventaja.

Animaría a la holgura a ser utilizada para la mejora personal. Claro, extraiga historias del trabajo atrasado, pero asegúrese de pasar un tiempo libre: aprenda un nuevo idioma, practique su oficio con un kata, refactorice algunas cosas, modifique, refine o escriba nuevas herramientas para ayudarlo, ir y hablar a un interesado, colega o cliente, descubra lo que hace su equipo de control de calidad, tómese el tiempo para comprender cómo funciona su proceso UX.

Hay una gran lista de cosas que puede hacer que proporcionarán valor a su negocio y a usted mismo Y mejorarán su velocidad o la cantidad de valor de calidad que brinde que no implique sacar cosas de una cartera de pedidos, intente esas primero.