Perdóname si esto se ha preguntado antes, leí algunas preguntas similares (vinculadas a continuación), pero no encontré la respuesta que estaba buscando.
Nuestro equipo es bastante nuevo en ellos y está tratando de averiguar cómo aplicarlos mejor.
Aquí está el problema, por sprint;
250xXXS (1)=250
1xXL (20)=20
¿Cómo se puede medir la velocidad de un equipo cuando este es el caso? Hay una diferencia de 10 veces en la velocidad de un desarrollador dado.
Nuestra tabla de tallas (Fibonacci-ish)
| XXXS | XXS | XS | S | M | L | XL | XXL | XXXL |
|------|------|------|------|------|------|------|------|------|
| 1 | 2 | 3 | 5 | 8 | 13 | 20 | 30 | 50 |
Relacionado:
La respuesta oficial al problema es:
No hay números fijos. Si tiene más sentido que una gran historia tenga 100 puntos, hazlo. Si tiene más sentido tener historias de 1/2 punto, úsala. Usa ambos si es necesario.
Sin embargo, para su problema, es posible que desee ver sus historias de 1 punto. ¿Son esas realmente historias y cuál es su definición de hecho?
Suponiendo una semana laboral predeterminada de 40 horas y una duración de sprint de dos semanas, significaría que la persona tardó menos de 20 minutos por ticket. Eso ya incluye el hecho de que esa persona no tomó descansos, ni sorbos de café, ni baño, ni una sola reunión durante todo el sprint. En realidad, es probable que esté más cerca de 10 a 15 minutos por boleto.
Con nuestro DoD, no podría cerrar un ticket en 20 minutos. Tengo que abrirlo, leerlo y entenderlo, verificar el código actual, cambiarlo, escribir pruebas para el cambio, preparar los datos para la revisión/demostración, confirmar, enviar, solicitar fusión e instalar mi código en algún lugar para revisión/demostración. Incluso para un error tipográfico de un solo carácter, lleva entre 15 y 20 minutos escribir, hacer clic en los botones y esperar los resultados.
Con 250 historias que son tan pequeñas, me preguntaría si tener puntos de historia para ellas es útil. De sus 251 historias en el sprint, 250 se completan más rápido de lo estimado . Tal vez sea mejor que te organices de otra manera.
Tal vez permita que las personas trabajen en el flujo de tickets aparentemente pequeños y solo si encuentran uno particularmente grande, eso se eleva a un elemento pendiente para el equipo. Lo que normalmente sucede es que una empresa tiene dos equipos, uno para las operaciones diarias (también conocido como 250 tareas súper pequeñas) y otro para el desarrollo que se enfoca en trabajar en las grandes historias.
Intente dividir las grandes historias de usuarios en partes más manejables (menos de un día para hacerlo), puede resolver su problema. Si aumenta la dureza de la historia de usuario, la dificultad de resolución puede aumentar de forma no lineal, como puede ver en los puntos de su historia.
La base de la estimación relativa (que es para lo que se usan los puntos de la historia) es que 1 punto siempre representa aproximadamente la misma cantidad de esfuerzo. Esto debe ser independiente del tamaño de la tarea.
Esto significa que una tarea de 20 puntos debe requerir aproximadamente 20 veces más esfuerzo que una tarea de 1 punto (aunque el esfuerzo real gastado puede variar fácilmente entre 10 y 40 veces más debido a las incertidumbres de la estimación).
En su ejemplo, si un solo desarrollador puede terminar 250 tareas XXS o una tarea XL, entonces la tarea XL es aproximadamente 250 veces más grande que una tarea XXS, no las 20 veces que sugieren los valores de puntos de su historia. Esto significa que su asignación de puntos de historia a los tamaños de camiseta es incorrecta o que la tarea XL está muy subestimada.
Ok, te daré una mejor tabla de tallas. Creo que el problema es que configuraste el sistema equivocado.
Antes que nada, tienes que:
Mejor tabla de tallas
USER STORY SIZE TIME ESTIMATE
0 (-)
1/2 (<1/2 h)
1 (1/2 - 1 h)
3 (1 - 2 h)
5 (2 - 4 h)
8 (4 - 8 h)
13 (8 - 16 h)
20 (16 - 24 h)
40 (24 - 40 h)
100 (40 - 80 h)
Nota: la estimación del equipo es el promedio de todas las estimaciones
nvoigt
Tiago Cardoso
mamada
Tiago Cardoso
aventura2099