domingo, diciembre 25, 2016

Tres Métodos para Estimar la Velocidad (capacidad) de un Equipo Scrum en el Primer Planning



Hola a todos

Uno de los primeros retos que enfrenta un Scrum Master con su Equipo es realizar el primer planning, pues para este no hay velocidad anterior (1), quiero compartirles tres propuestas de como se hace este cálculo, las cuales son muy sencillas, pues la verdad en la agilidad preferimos invertir más tiempo en el desarrollo de software que en la estimación que a la larga siempre fracasamos en ellas y terminan siendo un desperdicio.

Demos inicio.


Datos de entrada
  • Un equipo multifuncional de 6 personas
  • Un Product Owner (obviamente, no esperaría menos)
  • Un Scrum Master (obviamente, no esperaría menos)
  • Un sprint de 10 días)
  • Días de reuniones del sprint: 1.5 días aproximadamente  (ver tabla de tiempos reuniones de Scrum - clic aquí -)
    • Planning medio dia
    • Review y retrospectiva medio día
    • Refinamiento máximo el 10% del tiempo del sprint
  • Días efectivos del sprint: 8.5 días (8.5 días = 10 días del sprint - 1.5 días de reuniones)
  • Días-persona disponibles para el producto: 51 días-persona/sprint 
    • (8.5 días x 6 personas = 51)

Método 1: Un día-persona es igual a un punto (punto de historia)

Los pasos son los siguientes:
  1. Determino cuantos días-persona tengo (datos de entrada: 51 días-persona)
  2. Le presento al equipo una funcionalidad, por ejemplo la siguiente pantalla, con todos sus criterios de aceptación
  3. Les pido que estimen la totalidad de esfuerzo(2) requerido en días(3) para realizar las siguientes actividades correspondientes a una Definition of Done:
    • Análisis de la historia de usuario
    • Diseño
    • Implementación (desarrollo)
      • Web services (Si es que los hay)
      • Modificaciones a la base de datos (si es que los hay)
      • Codificación
    • Pruebas unitarias
    • Inspección o prueba par
    • Realizar correcciones fruto de la inspección par (o prueba par)
    • Despliegue en ambiente calidad
    • Ajuste en calidad
    • Elaboración de casos de prueba
    • Probar
    • Reportar las pruebas
    • Corregir en ambiente de desarrollo
    • Despliegue en Calidad
    • Volver a probar
    • Hacer los manuales o documentos que al cliente le agregan valor (manual de usuario, manual técnico o cualquier otro documento de la Definition Of Done)
    • Alguna otra actividad de la Definition of Done
  4. El equipo estima que para esto por ejemplo toma 2 días de esfuerzo entonces son 2 puntos (o puntos de historia)
  5. Y la velocidad máxima que tendrá ese equipo en este sprint y en los demás sprints será de 51 puntos
  6. Luego se siguen estimando el resto de historias de usuario hasta que se se llega a la velocidad del sprint

Ventajas

  • Para toda la organización y todos los equipos la medida es única (1 día-persona = 1 punto)
Desventajas
  • Los equipos tienen velocidad estática, aunque mejoren sus procesos, interacciones, forma de trabajo, se automaticen tareas repetitivas su velocidad será siempre la misma
  • Serán fiscalizados en función los puntos que son capaces de lograr debido a la cantidad de integrantes y presionados a lograr el 100% de lo comprometido


Método 2: Un punto (punto de historia) es igual a una funcionalidad pivote

  1. Determino los días persona (datos de entrada: 51 días-persona)
  2. Le presento al equipo una funcionalidad, por ejemplo la siguiente pantalla, con todos sus criterios de aceptación
  3. Les pido que estimen la totalidad de esfuerzo(2) requerido en días(3) para realizar las siguientes actividades correspondientes a una Definition of Done:
    • Análisis de la historia de usuario
    • Diseño
    • Implementación (desarrollo)
      • Web services (Si es que los hay)
      • Modificaciones a la base de datos (si es que las hay)
      • Codificación
    • Pruebas unitarias
    • Inspección o prueba par
    • Realizar correcciones fruto de la inspección par (o prueba par)
    • Despliegue en ambiente calidad
    • Ajuste en calidad
    • Elaboración de casos de prueba
    • Probar
    • Reportar las pruebas
    • Corregir en ambiente de desarrollo
    • Despliegue en Calidad
    • Volver a probar
    • Hacer los manuales o documentos que al cliente le agregan valor (manual de usuario, manual técnico o cualquier otro documento de la Definition Of Done)
    • Alguna otra actividad de la Definition of Done
  4. El equipo estima que para esto por ejemplo toma 3 días de esfuerzo 
  5. Se considera esa funcionalidad será el pivote y es igual a 1 punto y que estimemos relativamente el resto de las historias de usuario o pantallas según el caso.
  6. La velocidad esperada ese primer sprint será = 17 puntos (51 días-personas/3 días =17 puntos) 
  7. Para la siguiente historia saco el lapicero de Will Smith de Men in Black y pido que miren fijamente, diciéndoles que olviden el cálculo 1 punto es aproximadamente 3 días y que sigamos pensando solo en la pantalla y estimemos relativamente respecto este pivote.
    Equipo por favor miren a acá un momento y olviden que esta historia de usuario toma 3 días.
  8. Se siguen estimando el resto de historias de usuario hasta que se se llega a la velocidad del sprint

Ventajas
  • Se desvincula el concepto de días u horas a las estimaciones
  • Los equipos encuentran mejores formas de interactuar y de resolver los problemas con el tiempo, por lo tanto con seguridad habrá aumento de velocidad y esta pantalla que en inicio tomaba 3 días es probable que al sexto sprint tome menos viendo la organización de forma tangible la mejora del equipo.
Desventajas
  1. Se pierde el “control” basado en días
  2. Los equipos no tienen velocidad estándar

Método 3: "Ojo de buen Cubero" o "nos comprometemos hasta aquí"

  1. El equipo escucha las historias en orden, resuelven el qué y el cómo de cada una de ellas.
  2. hasta un momento donde el equipo dice: "Somos capaces con estas historias, paremos el planning"
Ventajas
  • Se desvincula el concepto de días u horas a las estimaciones
  • Es necesaria la confianza en el equipo
Desventajas
  1. Se pierde el “control” basado en días
  2. Los equipos no tienen velocidad estándar



Concluyendo

De estos tres métodos sugiero más al método 2 (aunque por años usé el método 1) y con equipos maduros al método 3. Espero que este post les sea de ayuda en su primer planning,

Saludos ágiles

Jorge Abad




Importante: compartí un cuarto método en: Un Cuarto Método para Estimar la Velocidad (capacidad) de un Equipo Scrum en el Primer Planning (clic aquí)



Notas, referencias, comentarios y observaciones

  1. Para la estimación de la velocidad o capacidad del segundo sprint se usa un concepto que se llama “el clima del dia anterior”, y se basa en la premisa si ayer hizo un clima es muy probable que hoy haga el mismo clima, si el sprint pasado hicimos 30 puntos es muy probable que estemos cercanos a ese puntaje, entre 25 y 35, ya es potestad del Equipo y del ScrumMaster si van más allá o nó. Lectura Recomendada Comprometiéndonos un poco más allá en el planning - clic aquí- )
  2. Obvio es probable que entre una actividad y otra toque esperar un tiempo, pero nos estamos refiriendo solo a tiempo de trabajo y no se incluyen tiempos de espera)
  3. Se sugiere en días, pues  de esa manera se amortiguan las malas estimaciones.
  4. Lectura recomendada:Uno de los objetivos secundarios del planning no es la puntuación, sino determinar con cuanto se compromete el equipo dada su capacidad (clic aquí)
  5. Libro recomendado: Scrum y XP desde las trincheras (clic aquí)

No hay comentarios.:

Publicar un comentario