15 Estimaciones

¿Cómo hacer las estimaciones?

• Estimaciones relativas usando Story Points: En lugar de estimar el tiempo absoluto necesario para completar una User Story, se estima cuánto esfuerzo demanda en comparación con otra. Se asignan puntos, llamados Story Points, como resultado de estas comparaciones relativas. Por ejemplo, una User Story con un valor de 2 requerirá el doble de esfuerzo que otra de 1. Los valores usados como Story Points pertenecen a una escala discreta, como la sucesión de Fibonacci. Limitarse a valores discretos simplifica el proceso. Si bien es frecuente usar Story Points, estos no son fundamentales dentro del concepto de estimaciones relativas. Se pueden usar tallas de remera u otra medida.
• Planning Poker: Se puede utilizar esta técnica para asignar estimaciones a las User Stories. Se invitará a todo el equipo que participará en el proyecto (desarrolladores, testers, diseñadores y Product Owners). Se les entregará mazos de cartas donde cada una representa un número de Story Points. El proceso es el siguiente:
  1. El Product Owner describirá la User Story, qué desea lograr y cómo aportará valor.
  2. Se debate brevemente sobre qué implica y qué riesgos existen.
  3. Cada persona piensa y elige su carta.
  4. A la cuenta de 3, todos muestran la carta seleccionada simultáneamente.
  5. Se cuenta cuántas personas eligieron cada carta. Generalmente, la distribución sigue una campana de Gauss, con la mayoría eligiendo un valor similar.
  6. Es importante escuchar a los outliers (estimaciones muy bajas o altas) ya que pueden tener información que el resto desconoce.
  7. Se busca llegar a un consenso.
• Estimando el Backlog: Se selecciona una User Story que se considere de las más pequeñas del Backlog y se le asigna 1 punto. Luego se estima, usando Planning Poker, la primera User Story del Backlog, comparándola con la anterior. Se continúa con las siguientes User Stories. El sistema se estabiliza rápidamente y estas primeras estimaciones establecen el parámetro para todas las demás. Se delimita el tiempo para la estimación de cada User Story (por ejemplo, 5 minutos). Si el equipo es numeroso, se pueden repartir las User Stories entre grupos para estimar en paralelo.

¿Qué implica la estimación?

• Completar una User Story: No basta con "codear" la funcionalidad. Se deben ejecutar exitosamente todos los casos de prueba, el Product Owner debe validar y aceptar la User Story, y deben existir tests automatizados para la nueva funcionalidad. Estos puntos constituyen la definition of done. Es importante que todo el equipo entienda lo mismo sobre lo que significa completar una User Story.
• Costo y tiempo de trabajo: Para traducir los Story Points del Backlog a una unidad de tiempo, se estima 1 Story Point con el equipo elegido, infiriendo así el tiempo total del Backlog. Por ejemplo, si el Backlog inicial se estima en 75 Story Points y se tiene un equipo de 3 personas, se estima cuánto llevaría completar 1 Story Point con este equipo (ej: 1 día). Así, se demorarían 75 días en terminar. Para hacer un presupuesto, se multiplica este número por la cantidad de personas en el equipo y por la cantidad de horas que trabajan en promedio.
• Velocity y Burndown: Se mide la cantidad de Story Points que se pueden terminar en cada iteración, lo que da una pauta de la verdadera capacidad del equipo (Velocity). Midiendo la Velocity de la primera iteración, se puede inferir cuánto queda por delante. Con esta información, se actualiza el plan: ¿Se puede extender la fecha de entrega? ¿Se puede acotar el scope? ¿Se podría aumentar la Velocity sumando un integrante más?.
• Aspectos importantes:
  • Se hacen sobre User Stories, es decir, incrementos de funcionalidad visibles al usuario final.
  • No se invierte mucho tiempo en un análisis detallado para la estimación porque la precisión no justifica la inversión.
  • No implican un compromiso. No se debe presionar al equipo para acortar los tiempos o cumplir con la fecha estimada inicialmente.
• Conclusión: Es necesario tener una idea de la dimensión del producto para poder planificar el equipo y proyectar tiempos, pero no se busca saber exactamente cuánto llevará ni invertir demasiado tiempo en intentarlo. Cuando se comience a desarrollar, se podrá verificar si las asunciones y estimaciones fueron correctas, plasmando el conocimiento adquirido en los planes. Usando Story Points y midiendo la Velocity, esto es automático.

---

← Backlog · Índice · Velocity →