3 formas de abordar el trabajo de sprint que termina antes

4 Formas De Manejar La Gestión De Defectos Durante El Sprint

Hace mucho tiempo, en un Scrum Team muy, muy lejos ...

Hay confusión en la Corporación de Ingeniería Corelliana, fabricantes de naves es-telares de carga. Scrum Team A-Tano, que recientemente aprendió el valor de la Definición de Terminado, está en el día siete de un Sprint de dos semanas. Una de las desarrolladoras, Lilly, comienza su contribución al Daily Scrum:

“Ayer, completé todo el trabajo de desarrollo de la API de retransmisión motivado-ra del hiperespacio. Está listo para probar. Todas las tareas restantes de este Sprint están en progreso y no hay nada que pueda hacer para ayudar a nadie más en el equipo, así que incluí una pequeña historia de usuario en la que trabajar. Lo agregué al tablero y creo que habré terminado con mi trabajo al final del Sprint ".

Leer más: 5 razones por las que las personas se resisten a las transformaciones ágiles

Inez, el Scrum Master, responde: "Equipo, ¿es ese el mejor curso de acción que podemos tomar?"

¿Qué crees que debería hacer el equipo en esta situación? ¿Por qué el Scrum Master le hizo esta pregunta a Lilly y al resto del equipo de desarrollo? ¿Es aceptable que un equipo incorpore nuevos trabajos al Sprint una vez que ha comenzado?

Como entrenadores ágiles, vemos esto todo el tiempo. Los miembros del equipo Scrum a menudo se preguntan qué deben hacer cuando se quedan sin trabajo durante un Sprint. A veces, son las personas, como Lilly, las que terminan antes de lo planeado. Otras veces, el Sprint Goal resulta ser más fácil de lo que el equipo piensa colectivamente, y todos terminan temprano. Entonces, ¿qué debería hacer un equipo Scrum cuando descubre que hay más capacidad que el trabajo planeado?

Primero, No Hagas DañoLo primero que debes pensar es en el consejo de la Guía de Scrum de "No hacer cambios que pongan en peligro el Sprint Goal". El propósito de un Sprint es crear un incremento de producto "Listo" potencialmente enviable; Ningún miembro del equipo debe agregar trabajo al Sprint de ningún tipo que pueda poner en peligro ese esfuerzo, ya sea porque causará problemas de integración, porque podría romper la funcionalidad existente o porque podría afectar el trabajo que aún se está realizando en el Sprint.

Cualquiera que sea la decisión que se tome, debe involucrar a todo el equipo Scrum- Product Owner, el Scrum Master y los miembros del equipo de desarrollo.

Aquí hay algunas cosas que un Scrum Team puede hacer cuando parece que se está quedando sin trabajo durante un Sprint:

1. Extraiga un nuevo elemento de la lista de trabajos pendientes del producto en el SprintComo equipo Scrum, es importante discutir qué elemento del Product Backlog se debe incluir en el Sprint. Se dará prioridad a un Product Backlog saludable y habrá elementos listos en la parte superior, que se pueden incluir en el Sprint Backlog.

El equipo de Scrum debe elegir el elemento de mayor prioridad que se puede terminar dentro del período de tiempo del Sprint. Eso podría ser:

■ Una historia de usuario■ Una partida de deuda técnica■ Un defecto■ Un pico

2. Toma acción para desempeñar mejor tu trabajoLos miembros del equipo a menudo sienten que el tiempo que no se dedica a tra-bajar en los elementos de la cartera de productos es un desperdicio. Pero es va-lioso tomarse un tiempo para el crecimiento profesional. Los miembros del equipo que experimentan un poco de tiempo de inactividad tienen más opciones que co-menzar a trabajar en un nuevo desarrollo:

■ Aprenda una nueva habilidad o perfeccione una existente, especialmente si el equipo tiene un trabajo nuevo o desconocido en el futuro cercano. No solo es un uso valioso del tiempo para usted, sino también para su equipo.

■ Respalde a algunos usuarios. Aumentar la capacidad del equipo para empatizar con los usuarios y clientes reales aumenta la probabilidad de que el equipo brinde soluciones que los complazcan.

■ Habla con el público interesado. Cuando los miembros del equipo desarrollan re-laciones con las partes interesadas, el equipo comprende sus dolores, metas, deseos y necesidades, y ofrece soluciones de alto valor.

■ Envíe a un miembro del equipo en una excursión de un día a otro equipo. Esto puede ayudar a un equipo a aprender una nueva forma de trabajar y puede mejo-rar las técnicas utilizadas por el equipo. Ver a otro equipo en acción puede inspi-rar mejores procesos y prácticas.

3. Refinamiento de BacklogEspecialmente si se avecina el final del Sprint, tal vez el día anterior, conseguir más trabajo en el Sprint actual es menos importante que estar preparado para el siguiente. Para prepararse para el éxito, los miembros del equipo pueden dedicar tiempo a revisar los elementos de la lista de trabajos pendientes de mayor priori-dad para asegurarse de que sean lo suficientemente independientes, del tamaño adecuado y que se entiendan claramente.

Equipo Scrum A-Tano¿Qué decide hacer Scrum Team A-Tano? Después del Daily Scrum, el equipo está de acuerdo en que no hay nada más que pueda hacer Lilly para ayudar al equipo a alcanzar su Sprint Goal. Acuerdan pasar un par de horas revisando su trabajo terminado para asegurarse de que cumpla con los estándares de calidad de Corellian y la Definición de Terminado del equipo.

Una vez que están satisfechos de que se ha cumplido el objetivo del Sprint y el trabajo está a la altura de los estándares del equipo, el propietario del producto les ayuda a seleccionar un PBI de alta prioridad que sea lo suficientemente pequeño como para que el equipo lo complete dentro del Sprint. El equipo de desarrollo inmediatamente comienza a trabajar en ello. Terminan el elemento de acuerdo con su Definición de Terminado con poco tiempo de sobra al final de su Sprint.

En el último día de su Sprint, realizan la Revisión de Sprint, que incluye la última incorporación a su Sprint Backlog. Al mantener su compromiso de producir un incremento de producto de alta calidad sin dejar que el trabajo se desvanezca, el Sprint del Scrum Team A-Tano tiene éxito, y hay un equilibrio temporal en el universo. ¿Está interesado en ver cómo se comparan sus revisiones de sprint? Realice nuestra evaluación gratuita.

Descubra cómo podemos ayudarle a escalar de forma ágil en toda su organización.

El Equipo Scrum debe planificar el elemento como lo haría durante la Planificación del Sprint. Esto implica asignar la tarea al elemento, estimar las tareas y acordar el orden en el que es más probable que ocurran las tareas para lograr la máxima eficacia.

El propietario del producto debe comunicar este cambio a las partes interesadas clave, según sea necesario.

Cosas a tener en cuenta:

Renovación del trabajo: si el elemento no se puede completar por completo al final del Sprint, el trabajo quedará al final, lo que podría causar problemas con el trabajo obsoleto y prioridades en conflicto. Si las prioridades cambian como resultado de la Revisión de Sprint, de modo que el PBI ya no es importante o deseado, entonces el trabajo se desperdiciará.

Expectativas poco razonables: tenga cuidado al establecer expectativas con las partes interesadas, para que no escuche esta pregunta: "¿Por qué no puede hacer X puntos de historia CADA Sprint?"

Mala calidad: antes de realizar un trabajo nuevo, asegúrese de que el trabajo comprometido realmente haya cumplido con todos los estándares de calidad y la Definición de Terminado, y que sea realmente potencialmente apto para el envío.

Leer más: 4 formas en que Scrum lo ayuda a aceptar los requisitos cambiantes

https://agilethought.com/blogs/3-ways-tackle-sprint-that-ends-early

Copyright 2021 AgileThought, Inc. – Privacy Policy – Terms of Use

Descargue AgileIgnite One-Pager