¿Cuántas historias de usuarios por persona deben completarse por sprint? [cerrado]

Acabo de encontrar esta figura y me pregunto si hay otra fuente bien conocida que pueda ayudar a confirmar estos números:

Con base en los datos que analicé en sprints finalizados con éxito, determiné que un equipo debería promediar alrededor de 1 a 1-1 / 2 historias de usuarios (elementos de la cartera de productos de cualquier tipo, realmente) por persona por sprint.

FUENTE: El blog de Mike Cohn sobre " ¿Debería el Standup diario ser persona por persona o historia por historia ?"

La productividad está influenciada por una serie de factores: cultura organizacional, experiencia con el lenguaje y las herramientas, conocimiento del proyecto, detalles del proceso que se está utilizando, factores externos tales como regulaciones y capacidades del equipo como unidad cohesiva. Por eso, al estimar proyectos, los datos más útiles son los del equipo específico que llevará a cabo el trabajo. A medida que se generaliza en la organización, la industria y luego en los proyectos de software, la productividad se convierte en un área confusa.

Una de las ventajas del desarrollo iterativo es que pasa por todas las fases muchas veces en un solo proyecto, lo que le permite obtener una visión del proceso y del equipo. Puede comenzar con datos organizativos de proyectos anteriores, pero muy rápidamente (2-4 iteraciones) obtiene datos específicos del equipo para la planificación del proyecto.

El número que cita (1-1.5 historias de usuario por sprint) es el nivel más alto de abstracción. El mejor momento para usar este número es cuando no tiene datos específicos de la industria del dominio en el que se encuentre su producto, ni datos de la organización, ni datos específicos del equipo, al principio de sus primeros proyectos con Scrum. Probablemente proviene de equipos que utilizan todo tipo de variantes de Scrum, incluida la combinación de Scrum con otras técnicas de mejora de procesos (Kanban, CMMI, Lean). Confiaría en usar este número tal como está, ya que Mike Cohn y Mountain Goat Software son consultores ágiles muy respetados. Sin embargo, tan pronto como tenga datos de su organización (o, mejor aún, de su equipo), úselos para planificar sprints.

Sería algo de lo que preocuparse o incluso tratar de medir, este número variará ampliamente según la habilidad del programador, la complejidad de la historia, la experiencia del programador y el equipo, la experiencia de aquellos que crean historias, la capacidad de mantenimiento de la base de código ... .

Debería estar preocupado por cosas como si todo el mundo parece estar contribuyendo a lo mejor de su capacidad, ¿está el cliente más feliz hoy que ayer? ¿Todos / la mayoría piensan que este proceso está funcionando mejor que el último proceso que probamos?

Creo que, en un nivel detallado, decir "todos deberían completar 1.5 historias por sprint" es la interpretación arriesgada del análisis. Lo que he encontrado es que, con el tiempo, el equipo decide especificar historias de complejidad similar. Forma una línea de base por la cual puede planificar adecuadamente en el futuro. En otras palabras, velocidad. Nunca me gusta medir la velocidad por número de historias, sino por puntos de la historia. En general, aunque desaparece debido a la diferencia de tamaño entre las historias (las historias más pequeñas compensan las historias más grandes).

Es agradable ver que él discute las diferencias en la duración del sprint (los sprints más largos tienden a abordar historias más grandes) y el tamaño del equipo en el impacto aquí. También al abrir la cortina (es decir, tener tareas detalladas relacionadas con las historias) proporciona una mayor visibilidad de lo que implica completar la historia (que en última instancia es de lo que se trata esa publicación: visibilidad).

Por lo tanto, como regla general, Cohn dice apuntar alrededor de 1-1.5 historias por desarrollador por sprint. Mucho más que eso, y te arriesgas a no escuchar el progreso de una historia hasta que estés en un sprint. Lean aborda esto dejando historias en la cartera de pedidos hasta que estén listas para ser desarrolladas. Lo que Mike dice es que su trabajo efectivo en progreso para el desarrollo debe limitarse a 1.5X, donde X es el tamaño del equipo de desarrollo.

Para mí, depende de tu sprint o del nivel de tarea a realizar. Desde mi experiencia actual, estoy trabajando en un sistema que creamos varias historias de usuarios. para cada semana haríamos historias asignadas para esa semana, si se realizan todas las tareas. pasamos al siguiente sprint aunque estemos adelantados (suponiendo que la tarea se haya realizado correctamente)

en mi equipo para cada persona tiene 3 historias que hay que hacer. y me sorprende que estemos superando nuestras limitaciones.

solo depende del programador. pero cosas como esta no deberían ser un problema. El problema aquí es que el cliente obtendrá lo que quiere o pide.

Lo último que escuché fue que era 1.5 / 2x el número de miembros del equipo.

También tenga en cuenta que Mike Cohn no implica que deba usar estos números, simplemente está diciendo que a lo largo de los años en la industria y los muchos equipos que ha entrenado, ha encontrado 1.5x / 2x historias por miembro del equipo para que funcionen mejor. Dio esta respuesta cuando le pregunté qué consideraba que era el tamaño ideal de la historia del usuario.

Pregunta tonta, pero ¿no se expulsa la respuesta a través de a) la estimación inicial del equipo de los puntos de la historia (o lo que sea) de cualquier sesión de planificación de sprint y luego b) la velocidad de sprint y / o la quema?

A veces alcanzamos las estrellas en el primer sprint y luego descubrimos rápidamente que no todas las historias son lo que parecen (algo siempre oculto). Luego reajustamos nuestras próximas estimaciones de sprint para el siguiente menú desplegable de la historia de la cartera de pedidos.

Una o dos historias como máximo por desarrollador es el tipo de destino de la mayoría de los proyectos de aplicaciones móviles de mi equipo, en una variedad de organizaciones, proyectos y desarrolladores de plataformas.