Estimación de esfuerzo

Uno de los puntos críticos de nuestra profesión, y una de la fuentes mayores de problemas es la estimación, existen muchos factores de riesgo, rotación de los equipos, trabajo con tecnologías nuevas, falta de procedimientos claros a la hora de estimas, sin olvidar que en ocasiones el alcance del proyecto lo marca el presupuesto de licitación.

La importancia del esfuerzo

  

En general todas se basan en el tiempo que puede durar una tarea, y en ese punto es donde radica la diferencia de nuevas propuestas de estimación. Dado que dos tareas una fácil y una de dificultad máxima pueden tardar lo mismo en tiempo ... pero ¿Tiene sentido a nivel de planificación que la consideremos igual a nivel de esfuerzo? La respuesta es NO

Uno de los problemas habituales es que cuando desarrollamos nos resulta difícil predecir cuanto tiempo va a necesitar la tarea. Más si cabe con variables inciertas como el nivel de interrupción que se va a tener, si va a paralelizarse con otras tareas, etc. 

Una primera recomendación es estimar en esfuerzo y no en duración.

La velocidad

La velocidad en sí misma es una métrica beneficiosa para el equipo, y es importante no variar la fecha de finalización de una iteración o sprint, ni contabilizar en la velocidad tareas que no esten "DONE DONE", para que la métrica tenga ese impacto positivo indirecto.

En primer lugar para conseguir si el equipo trabaja por debajo de lo previsto, la velocidad se ajusta para la siguiente Iteración, adaptándose por tanto a la capacidad del equipo. Y a la inversa, en el caso de conseguir más historias de las previstas.

No hay que perseguir con desmesura una velocidad excesiva como premio, recordemos que uno de los principios ágiles es la de tener un ritmo de trabajo sostenible!!

La estimación

Existe cierta ansiedad compartida a la hora de que un miembro del equipo de una estimación, la realidad es que la mejor manera de hacer buenas estimaciones es hacer muchas estimaciones y seguramente equivocarte un un porcentaje elevado de las mismas. Aplicando Slack si el riesgo es excesivo para conseguir los compromisos adquiridos.

Es por ello que resulta importante que todo el equipo participe en las estimaciones, es importante que se justifiquen, ya que fomenta la compartición de conocimiento y el razonamiento de la valoración.
Volviendo a la hacer referencia al esfuerzo, es una buena opción valorar de manera optimista y considerando que no van a producirse interrupciones, durante el proyecto nuestra experiencia nos permitirá ajustar mejor en base a la situación real del proyecto. Y como recomendación de granularidad siempre mejor horas que días.

Planning Poker


Considerando los puntos anteriores, así como la influencia que tienen el product owner, el cliente, o los miembros más séniors del equipo de desarrollo, uno de los procesos más consolidados en la estimación es el denominado Planning Poker.

El proceso es sencillo:

1. El product owner o cliente enuncia la funcionalidad
2. Todos los presentes muestran sus estimaciones simultáneamente con una carta, pizarra, papel ...
3. Se debaten las diferencias de estimación, y se vuelve a realizar la estimación hasta que las estimaciones del equipo se alinean

Este método funciona por lo divertido que puede llegar a ser, tratándose de un juego, pero también por la aportación intelectual que comparten los recursos y el cliente.

Esta técnica puede ser utilizada para definir los story points, necesarios para que el Product Owner priorice su Product Backlog y defina que funcionalidades van a incorporarse al Sprint. Y también para la estimación propia de cada tarea del Sprint Backlog.

Referencias

• James Shore - Estimating
• VersionOne - Feature Estimation
• AgileSoftwareDevelopment - Estimation
• ScrumMethodology - Estimation and Story Points
• ProyectosAgiles - Estimación y planificación ágil
• Presentación de SlideShare de estimación con SCRUM

Saludos,