¿Se deben asignar historias de usuario a todos los miembros del equipo?

Esta es una pregunta muy básica, pero todavía no veo ninguna respuesta.

Escenario: Hicimos la planificación del sprint y noté que alguien decía

No todos los desarrolladores tienen una tarea que hacer. Necesitamos agregar más tareas para que todos tengan trabajo.

Tengo un problema con eso por las siguientes razones:

  1. Si nuestra velocidad es 60 y agrega tareas para que todos tengan trabajo, puede terminar superando su velocidad promedio, se está preparando para el fracaso.
  2. Con Agile prefiero promover la programación entre pares en lugar de que todos hagan una tarea y cuando finaliza el sprint tenemos más tareas en desarrollo que las que están cerradas.

Idea Tal vez las historias deberían dividirse para que cada miembro del equipo tenga una tarea, pero en todos trabajen hacia el mismo objetivo.

Pregunta: ¿Le da a cada miembro del equipo una historia de usuario o planifica de acuerdo con la velocidad y luego el equipo debe trabajar en conjunto para entregar un sprint potencialmente liberable en lugar de un sprint a medio completar?

¿Tienes experiencia en esto y cómo lo enfrentaste?

¿Cuál es tu papel en el equipo?
Scrum master recién nombrado

Respuestas (2)

Pregunta: ¿Le da a cada miembro del equipo una historia de usuario?

A ver un anti-patrón aquí. Como Scrum Master, no tiene que asignar historias y tareas a los miembros del equipo. Es su trabajo (bajo su liderazgo de servicio) autoorganizarse y elegir los elementos del backlog del sprint. Pueden usar técnicas de enjambre, pueden programar en pares, pueden desglosar las tareas técnicas en un nivel granular para trabajar en equipo y cumplir con su compromiso: el Sprint.

planificar de acuerdo con la velocidad y luego el equipo debería trabajar en conjunto para entregar un sprint potencialmente liberable en lugar de un sprint a medio completar?

Esta es mejor. Recuerde que las estimaciones son una conjetura después de todo. Por lo tanto, la velocidad es una medida más precisa contra la cual puede planificar su próximo sprint. No caiga en la trampa de asegurarse de que todos se utilicen al 100%. En su lugar, concéntrese en la optimización al 100%. En las reuniones retrospectivas del equipo, la velocidad actual también puede ser objeto de discusión. ¿Piensa el equipo que su velocidad es baja? Tal vez se hayan vuelto lo suficientemente eficientes como para que la velocidad pueda aumentar al planificar más historias en el próximo sprint.


En una nota relacionada, hay dos puntos de vista sobre la asignación de tareas a miembros individuales del equipo durante la reunión de planificación del sprint. Un argumento es tener nombres contra todas las tareas del sprint cuando finaliza la reunión de planificación del sprint. El segundo punto de vista es que la asignación de tareas no debe realizarse en la reunión de planificación del sprint. Deje que el equipo elija tareas a medida que avanzan, con la finalización de sprints como objetivo común.

Mike Cohn menciona en su blog :

Si un equipo sale de la planificación de sprints con un nombre al lado de cada tarea, definitivamente aumentará la responsabilidad individual. Me sentiré más responsable de terminar las tareas con mi nombre o mis iniciales al lado. Y tú sentirás lo mismo por aquellos con los tuyos. Pero, esto vendrá a expensas de la responsabilidad del equipo.

Mi recomendación es que un equipo deje la planificación de sprints sin haber puesto nombres a las tareas. Seguir una estrategia de registro en tiempo real permitirá una mayor flexibilidad durante el sprint.

Más sobre esto:

No creo que se pueda escribir una mejor respuesta que la que Aziz ha puesto aquí. Excelente y bien elaborado.
@ Venture2099 gracias por las amables palabras :)

En primer lugar, no damos ni asignamos una historia a un miembro del equipo. Deberían elegirlo ya que son autoorganizados.

El compromiso para el sprint (cuánto podemos hacer) se decide en función de la velocidad del equipo.

Es responsabilidad del equipo asegurarse de que lo comprometido para el sprint se cumpla colectivamente. Eso no significa que todos trabajen una sola historia, pero si un miembro del equipo está atascado, esto se hace transparente en el scrum diario o incluso antes. El equipo interviene según sea necesario y se asegura de que el problema se resuelva y la historia se complete.