domingo, diciembre 10, 2017

Un Cuarto Método para Estimar la Velocidad (capacidad) de un Equipo Scrum en el Primer Planning





Hola a todos

Hoy quisiera compartir un cuarto método de los tres anteriormente compartidos en el post "Tres Métodos para Estimar la Velocidad (capacidad) de un Equipo Scrum en el Primer Planning" - (clic aquí para leerlo).

Es muy parecido al ojo de buen cubero.

El proceso es sencillo


  1. Se toma una historia de usuario que todo el esfuerzo (1) requerido para construirse tome entre uno y dos  días-persona (o sea, si sumas todas las horas usadas para construir la historia de usuario sin considerar tiempos muertos tome entre uno y dos días) - Consejo: entre más cercano a un día de esfuerzo es mejor - de ahora en adelante esa será la historia pivote (2) y tendrá el tamaño de un punto
  2. Luego pregúntale al equipo. ¿cuántas historias pivote o de un punto son capaces de hacer en un sprint?
  3. El equipo hará su estimación y dirá por ejemplo somos capaces de hacer 20 de esas.
  4. Ok, acabas de tener la capacidad de tu equipo
  5. Ahora si, con esta información comienza el planning y compara todas las historias con respecto a la historia de usuario pivote, preguntando por ejemplo ¿esta nueva historia es 1,2,3,5,8 veces la historia pivote?, El equipo realizará planning póker y sumaras los puntos hasta que llegues a un número cercano a 20.
Otro punto importante a tener en cuenta, también determina cual es tamaño máximo que el equipo puede aceptar de historia de usuario, es decir
  • Si el sprint es de 2 semanas, es decir 10 días hábiles, y 8 de ejecución quitando las reuniones de planning, dailys, refinamiento, review, retrospectiva
    • si la historia es de aproximadamente 1 día, el tamaño máximo deberá ser 8 puntos, 13 puntos sería imposible de lograr
    • si la historia es de aproximadamente 2 días, el tamaño máximo deberá ser 5 puntos (y eso con un alto riesgo de no lograrse)
Y recuerda una buena práctica es que tu sprint backlog tenga entre 6 a 10 historias de usuario de similar tamaño

Hasta acá este corto compartir.

Saludos Ágiles 

Jorge Abad


Notas, Aclaraciones, Comentarios y Referencias

  1. Esfuerzo es diferente a Duración, algo te puede tomar 2 días de esfuerzo pero la duración puede ser 3 pues hay tiempos muertos entre una tarea y otra hasta completar la historia de usuario
  2. Hace un tiempo realice una tabla de tamaño de historias de usuario de acuerdo al tamaño del sprint (http://www.lecciones-aprendidas.info/2017/05/Tamanos-sugeridos-de-historias-de-usuario.html ), cada vez me convenzo más que deben ser lo más pequeñas posibles. 

4 comentarios:

  1. Doc, como siempre, muy acertadas tus reflexiones ágiles. Este método, como los otros tres que expones con tan buenos como tantos otros de los que hemos hablado.

    Sin embargo, se me ocurre que, si lo que queremos es dejar de lado la estimación, por los inconvenientes que esta trae, promover tantos de estos métodos nos arraiga a ellos en vez de distanciarnos de los mismos.

    Creo que debemos empezar a alejarnos de la raíces de lo que nos aqueja del pasado y comenzar a experimentar con nuevas ideas.

    ¡Hablemos de No Estimación!

    ResponderEliminar
  2. Claro un compañero habla mucho de Hacer lo importante hasta que deje de ser importante que es uno de los principios de #NoEstimacion o #NoEstimates

    La transición es dura pero es un paso que se debe dar

    ResponderEliminar
  3. Alexis Cuellar

    propone otro método: Hacer una HdU experimental previa al primer sprint, algo pequeño pero que involucre todo el equipo, el Hola mundo de las HdU, y en base a ese pivote estimar.
    Ahora para la velocidad hay varias, usar votación romana si entra o no cada HdU priorizada; un PH por cada persona; no estimar la velocidad inicialmente solo ver cuanto completan; etc.

    ResponderEliminar
  4. Hola @Jorge/@Luis

    Entiendo que lo que tendríamos sería un valor desde el inicio sobre cuánto puede llegar a generar el equipo. Esto pensando en que cumpla sus compromisos desde el inicio también. Esto para no desmoralizarlo cuando no lo cumpla? Creo que mi pregunta es en qué beneficiaría al equipo brindar el primer número lo más correcto posible? Abrazo.

    Como comentario aparte, vi este video https://www.youtube.com/watch?v=bGTLCEufS0A y en el minuto 5 hay un tema sobre la estimación que me pareció muy interesante; aunque no sé en qué aplicarlo, pero es interesante cómo funciona nuestra mente :)

    ResponderEliminar