El equipo de desarrollo no cumple con los plazos de sprint

No deberías asignar puntos de historia a las cartas. El equipo debe estimar las tarjetas y acordar qué sacar del trabajo pendiente en función de su velocidad.

El equipo es responsable de hacer sus propios pronósticos y planes de sprint. Decirles lo que se debe hacer en la próxima semana no es Agile ni Scrum. También es probable que desmotives a los miembros de tu equipo y perjudiques su productividad a largo plazo. Usted mismo, se está engañando a sí mismo pensando que asignar trabajo a las personas garantizará que se haga de acuerdo con el cronograma. También se está cegando para ver de antemano qué es más probable que se haga y qué no cuando no permite que las personas que realmente harán el trabajo le digan lo que creen que pueden hacer.

Una forma muy común de impulsar a las personas es hacer que se emparejen con un desarrollador más experimentado. Entonces, en lugar de que Joe y Bob trabajen en historias o tareas paralelas, pasan todo el día trabajando juntos en serie. Una historia o tarea a la vez. Esta es una forma de emparejamiento de XP, puede leer mucho sobre esto en la web.

Recibirá un golpe de productividad a corto plazo a cambio de una rampa más corta y ganancias de eficacia y/o eficiencia a largo plazo. El emparejamiento también hace maravillas por la calidad de su producto, la comunicación del equipo y la mejora continua.

Hago sprints de 1 semana con mi equipo de scrum, y todos los lunes hago una planificación de sprint donde asigno puntos de historia a las tarjetas

Tal vez deberías leer un libro o tomar un curso sobre SCRUM. Lo que estás haciendo no es SCRUM. O de alguna manera ágil. Dile a tu gente qué hacer y cuánto tiempo les llevará. Vosotros no sois un equipo. Eres el jefe y tienes empleados.

Si quiere hacer SCRUM, haga que su equipo calcule y planifique. Ellos son los chicos que tienen que hacerlo, deberían decirte cuánto tiempo tomará.

Tratemos de dar un paso atrás desde la perspectiva ágil/no ágil... scrum/no scrum.

Desglosando esto simplemente, si están haciendo el trabajo pero no haciendo tanto como pensaban que podrían, creo que es bastante normal. Estimar en una habitación con otras personas de todos los niveles de habilidad percibidos nos hace intentar y sobreestimar para compensar nuestras inseguridades inherentes.

Si el equipo está haciendo las cosas, trate de concentrarse más en mantener el trabajo interesante para todos en el equipo y asegúrese de que todos se diviertan.

Si el equipo tiene una visión clara del proyecto, entonces podría usar las historias más como un mecanismo de seguimiento en lugar de "compromisos". Esto le daría la capacidad de rastrear la velocidad y estimar el tiempo de finalización del proyecto, sin destruir la moral del equipo.

Desde la perspectiva de un economista, un trabajador podría simplemente comprometerse con una historia única, más fácil y con el punto más bajo que esté disponible cada semana para maximizar las posibilidades de que alcance la meta.

La forma de contrarrestar esto es tratar de mantener a la gente entusiasmada con lo que están trabajando. Incluso si es una tarea mundana, intente prestar atención a lo que motiva a cada miembro de su equipo e incluso reúnase con ellos individualmente y pregúnteles qué los entusiasmaría más con el proyecto.

Solo mis $0.02. He sido ingeniero de software durante 12 años y he pasado mucho tiempo trabajando con PM para ayudarlos a resolver este problema exacto.

Encara los hechos. Este tipo no va a volverse más productivo por arte de magia porque tienes una fecha límite. Consigue más desarrolladores en el equipo y alégrate por los que tienes.

Todo el mundo quiere fuerza delta para su misión; pero tienes que trabajar con lo que tienes.

Si está practicando Scrum, el problema no es que un programador esté "luchando por completar el trabajo para alcanzar el objetivo del sprint". El problema es que al equipo le cuesta cumplir el objetivo. La causa de esa lucha puede ser un miembro del equipo rezagado, el problema pertenece al equipo, no al individuo.

Entonces, su primera prioridad debe ser lograr que el equipo haga un mejor trabajo al estimar lo que pueden hacer en función de los recursos que tienen. Si el equipo sabe que un miembro del equipo se está quedando atrás, deben dar cuenta de eso. Si ha estado rastreando con precisión su velocidad, debe tener en cuenta que su velocidad es menor que la que está utilizando para fines de planificación.

Si descubre que el equipo no alcanza sus objetivos de manera constante en un 20 %, simplemente tómelo en cuenta cuando haga su planificación. Eso se puede lograr fácilmente eligiendo hacer uno o dos puntos menos por sprint.

Mientras tanto, si durante las retrospectivas descubre que un miembro del equipo no está haciendo todo lo posible, puede trabajar para resolver ese problema como un esfuerzo separado. Tal vez tenga un par de desarrolladores senior con ellos, o tal vez necesite moverlos a un rol diferente o darles más capacitación. Independientemente de la solución a ese problema, debe abordar por separado el problema del equipo que hace malas estimaciones.

Como otros mencionaron, scrum es un esfuerzo de equipo. Aunque en realidad, habrá algún tipo de barrera/separación, pero no debería parecer que son caballos en una pista de carreras enfocándose solo en ellos mismos al cruzar la línea de meta. La altura de esa barrera depende de la actitud/ego de los programadores. La programación en pareja es una buena manera de reducir esta barrera, a menos que uno de ellos no sea un jugador de equipo, será una configuración difícil. también, hacer una retrospectiva para evaluar el sprint. Si no pudo identificar la causa raíz del problema, entonces haga una conversación uno a uno, ¿podría ser que descubrió algo en el trabajo pendiente que no se anticipó, como fuera de las especificaciones o subestimó las tareas?

No sé cómo es la configuración de los dos programadores, pero yo había estado en la misma situación hace mucho tiempo. Para acortar la historia, necesito integrar el trabajo de otro programador (otro programador no es un buen jugador de equipo, lo que es peor es que quiere pasar al siguiente sprint por adelantado tan pronto como termine 'su' acumulación de sprints), siempre que diga el hecho, la administración simplemente se irá "wow". Tras la integración, algunos códigos tienen algunos errores, muchas secciones copiadas y pegadas, exceso innecesario y uso incorrecto de conceptos/patrones de diseño de programación orientada a objetos. Estar hecho no es solo estar hecho, debe estar hecho, bien escrito, probado y en una calidad aceptable.