¿Qué hacer si un miembro de un equipo termina todas sus tareas de sprint antes de lo previsto?

Corro sprints de 1 semana, últimamente mis sprints terminan antes de lo previsto (un día antes del final del sprint) para un miembro del equipo.

Sé que algunos PM esperan hasta el próximo ciclo de sprint, sin embargo, eso significa perder un día sin trabajar.

¿Cuál es la mejor manera de lidiar con esto?

Respuestas (4)

Tienes algunas opciones a tu disposición.

  • Use el tiempo disponible para trabajar en deudas técnicas o corregir errores.
  • Pídele al miembro del equipo que comparta la carga con otro miembro del equipo para ayudarlo a completar el trabajo pendiente del sprint porque es un equipo multifuncional y es su responsabilidad/compromiso compartido para entregar los elementos del sprint como equipo.
  • Elija el siguiente elemento de mayor prioridad del trabajo pendiente después de discutirlo con el propietario del producto. Intente dividir el elemento en una porción más pequeña o más delgada que pueda completarse en el mismo sprint.

Sklivvz escribió lo siguiente en esta respuesta :

puede agregar historias a un sprint en ejecución, si el equipo está de acuerdo. Sin embargo, no es una buena práctica, ya que reduce la utilidad y la capacidad predictiva de la metodología.

El mismo enfoque también se menciona en esta publicación de blog :

Le recomiendo que lleve a cabo una sesión de preparación del producto que, en este caso, actúa como una sesión de planificación de sprint de reducción para la pequeña cantidad de trabajo nuevo que podría caber en el tiempo restante. Si los nuevos elementos de la cartera de productos se completan antes del final del sprint, sus puntos de historia correspondientes contarán para la velocidad.

Pensé en hacer que un miembro del equipo ayudara al otro miembro del equipo que no había completado su sprint, el problema que tenía en ese momento era que no estaba capacitado para ayudarlo de todos modos. Por lo tanto, habría sido un desperdicio asignar el recurso de esa manera.
@bobo2000 sí, estoy de acuerdo. Con suerte, ahora el conocimiento del proyecto se comparte entre los miembros del equipo.
Agregaría un "cuarto punto", o consideraría combinarlo cada pocos sprints independientemente: "Déjalos trabajar en lo que más les importa". Es increíble lo que hacen los equipos cuando les permites ser autónomos en las prioridades de vez en cuando. Tal vez esté solucionando un molesto error heredado que siguen viendo en las demostraciones. Tal vez esté aprendiendo sobre una nueva pieza de tecnología.

Por lo general, con Scrum tenemos una cartera de productos que contiene una lista del trabajo que esperamos hacer en el futuro.

Al comienzo de cada sprint, el propietario del producto y el equipo se sientan y discuten qué historias llevar del backlog del producto al sprint. Muchos equipos usan una métrica llamada velocidad para determinar cuánto trabajo aportar al sprint.

Ahora bien, el sprint no siempre sale como se esperaba. Si hay trabajo sin terminar al final del sprint, entonces podemos reducir nuestra velocidad y así traer menos trabajo a los sprints futuros.

De manera similar, si el trabajo asignado al sprint se completa antes de que finalice el sprint, hacemos lo siguiente:

  • Hable con el propietario del producto y vea si hay historias preparadas en la cartera de pedidos del producto que podrían incluirse en el sprint.
  • Si traemos más trabajo y lo completamos al final del sprint, normalmente la velocidad aumentará y, como tal, traeremos más trabajo a futuros sprints.

Los equipos Scrum experimentados a menudo se asegurarán de que las historias en la parte superior de la cartera de productos sean pequeñas y estén listas para comenzar. De esa manera, si terminan el trabajo asignado al sprint antes de tiempo, será sencillo traer más trabajo.

La velocidad es un gran concepto, ya que te dice qué tan bien va el sprint en función de las historias de ese sprint. El único problema que tengo es que muy a menudo la velocidad depende de muchos factores, y para que sea consistente, las historias en cada ciclo de sprint tienen que ser similares. ¿Cómo lidias con eso? Según lo que ha dicho, ¿puedo traer más trabajo si terminan su sprint antes de tiempo? ¿En lugar de esperar a que comience el próximo ciclo de sprint?
Definitivamente traiga más trabajo si tiene la capacidad de completarlo antes del final del sprint. Aconsejaría no traer trabajo que sabes que no tendrás suficiente tiempo para completar. Tener una velocidad confiable puede ser un gran desafío. Un truco que ayuda es tener historias lo más pequeñas posible, lo que ayuda a reducir las variaciones entre las historias. Además, vale la pena discutir en sus retrospectivas si hay formas de reducir los factores que impactan en su velocidad.

Eres un PM que asigna tareas a individuos. Has usado la palabra sprint, pero no es scrum, ¿qué es?

La respuesta de Scrum sería que el miembro del equipo de desarrollo pasara a cualquier tarea que ayude al equipo a lograr sus compromisos. Ya sea retomar la 'tarea de otra persona' (esto no es algo en scrum) o emparejarse. Lo que pasa con el emparejamiento es que si el miembro del equipo carece de las habilidades para ayudar a otro, esto le ayuda a adquirirlas.

Recomendaría no hacer más trabajo hasta que el equipo tenga capacidad, no solo un individuo. Mejore la cooperación para que todos puedan trabajar primero en el trabajo actual en curso.

Bueno, en primer lugar, debe esperar y ver si se trata de un temporizador único. Si esto sucede con más frecuencia, discuta con el equipo por qué se comprometen con esta cantidad de puntos de historia, aunque es obvio que podrían manejar más.

También es una opción tener un pequeño proyecto de I+D, que se puede tramitar en tales casos. Tal vez tenga sentido debido a algunos objetivos estratégicos. Creo que también es una buena motivación.

Para ser honesto, nunca me he enfrentado a un escenario así, ya que aquí tenemos una política de errores primero, que generalmente son esfuerzos no planificados y, por lo tanto, reducen la cantidad de tiempo disponible para el desarrollo de características.

Editar

Como dije en los comentarios, está optimizando el rendimiento al repetir. Lo mejor de scrum es que hay un acuerdo entre PM y DEV, que se hace a la altura de los ojos. Este acuerdo debe ser ajustado, para que al final no quede nada y no se pierda tiempo. Es normal que al principio el acuerdo no sea ideal pero definitivamente lo será tarde o temprano.

Si ahora está optimizando desde su sitio dándoles una historia adicional dentro del sprint, es una situación jerárquica normal y podría disminuir la motivación del equipo.

Así que tenga paciencia y deje que el equipo aprenda sus lecciones tan bien como usted tiene que aprender las suyas. Digamos que la semana 1 el compromiso es de 30 SP y se realizan el jueves por la mañana. Luego, en la semana 2, el compromiso podría ser de 40 SP. Ahora no pudieron terminar. No hay problema, en la Semana 3 el compromiso debe ser de 35 SP. Rendimiento optimizado con 3 semanas. Por supuesto, es posible que te enfrentes al problema de que, aunque hayas encontrado un compromiso "ideal", el resultado está lejos de ser ideal. Pero esto también es normal, ya que se trata de seres humanos y no de máquinas.

Nuevo equipo, encontrando difícil obtener la velocidad perfecta. ¿Cómo puedo optimizar extremadamente los puntos de la historia?
@bobo2000: Bueno, especialmente en ese caso. Sientate y espera. Convéncelos de que tomen una historia adicional en el próximo sprint. Muéstrales un aumento relativo del rendimiento entonces. Es una buena motivación. Todos estos enfoques ágiles tienen una cosa en común. Todos son iterativos y su objetivo es optimizar el rendimiento al hacerlo, revisarlo, modificarlo y hacerlo...
¿Puedo agregar nuevas historias para compensar el tiempo restante?
@bobo2000: No, no en el sprint actual. Hubo un compromiso hecho por ambos sitios. Pero para el próximo sprint deberías pedir aceptar una historia más.
¿Y si agrego la historia adicional y no pueden completarla porque vale un día adicional?
@bobo2000: Bueno, lecciones aprendidas para el próximo sprint. Puede que no sea necesariamente otra historia, pero tal vez haya una historia más grande que pueda procesarse entonces.
Sí, entiendo, así que hipotéticamente, el desarrollador cumple su objetivo a mitad de semana, el miércoles. ¿Significa eso que tendré que desperdiciar jueves, viernes esperando que comience el próximo ciclo antes de delegar trabajo? Veo a lo que te refieres, pero no es práctico en un entorno comercial. Eso es 16 horas de trabajo perdido esperando.
@ bobo2000: vea mi edición.
@bobo2000 parece más convencido de los méritos de los conceptos de mando y control de las cosas, como la utilización del 100 % y el control directo del PM del trabajo, y menos en cosas más generales como la productividad general del equipo. ¿Está seguro de que no le gustaría reformular su pregunta en un lenguaje no ágil, para que pueda obtener la respuesta tradicional de comando y control que desea?
¿Qué hacer si un miembro de un equipo termina todas sus tareas de sprint antes de lo previsto?
RespuestasAquíPolítica de privacidad1y, 0v