Las Estimaciones en la Metodología Ágil

Las estimaciones en el mundo del software y los desarrolladores son duras. Existen muchos factores a tomar en cuenta cuando se trata de decir al Project Manager o al Product Owner el tiempo que nos tomará realizar determinada tarea.

Debemos entender que las buenas o malas estimaciones harán la diferencia en las decisiones que se tomen y a su vez estas afectarán a todo el equipo

No hay nada peor como tener que trabajar fines de semana, noches y hasta feriados para compensar una mala estimación o el hecho de no haber tomado en cuenta un factor importante a la hora de estimar el tiempo y/o dificultad en un desarrollo.

El Product Manager

En la Metodología de Desarrollo Ágil, el Product Manager es el encargado de priorizar el Backlog (la lista en la que se encuentran todos los requerimientos ordenados a tomar en cuenta para el desarrollo de un producto o Sprint en este caso).

Para el Product Manager es fácil capturar todos los requerimientos y necesidades del proyecto, pero a menos que se encargue de programar o desarrollar también el producto (si, algunos no tienen una vida social normal), se hace más difícil en el momento de entender todos los detalles de implementación.

Las buenas estimaciones por parte de los desarrolladores puede dar una perspectiva completa del nivel de dificultad y prioridad para cada ítem del Backlog. Cuando el equipo de ingenieros o desarrolladores se encuentran estimando, surgen preguntas y requerimientos importantes por parte de estos asi que realizar una buena reunión de levantamiento de estimaciones puede ser vital.

Para un Product Manager, conocer cuanto antes los niveles de prioridad y dificultad dados a cada requerimiento puede hacer la diferencia en la cantidad de tickets en el Backlog porque si una tarea contiene una dificultad muy alta, el Product Manager podría descomponer en partes más pequeñas las tareas que correspondan al mismo.

Las estimaciones son un deporte en equipo

Desarrolladores, diseñadores, testers, deployers…todo el mundo en el equipo es un miembro con diferente perspectiva del producto y el trabajo requerido. Por ejemplo, si el cliente desea agregar una nueva funcionalidad que parece fácil o simple, como algún soporte para un navegador, los de desarrollo y QA (o testers?), diseñadores y todos en el equipo deben sopesar todas las situaciones de un nuevo plus y evaluar este cada uno sobre la base de sus conocimientos, funciones y experiencias.

Story Points vs. Horas

Los equipos de desarrollo tradicional dan tiempos de estimación en formatos como días, semanas, meses, horas. Muchos equipos ágiles sin embargo han migrado hacia los Story Points. Los Story Points son una medida relativa de trabajo basado en la secuencia de números de Fibonacci: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Esto podría sonar contra intuitivo, pero esa abstracción es actualmente muy útil para validar los niveles de dificultad porque pone al equipo a tomar decisiones sobre el trabajo y no el tiempo que les tomara.

Algunas razones para usar los Story Points son:

• Los tiempos y fechas no toman en cuenta elementos como reuniones, emails, entrevistas con uno de los miembros del equipo, etc.
• Las fechas tienen un componente emotivo muy fuerte para el equipo. Las medidas relativas eliminan por completo este componente de presión.
• Cada equipo estimara su trabajo basado en su propia escala de dificultad, velocidad y naturalidad. Esto dará al equipo la capacidad de usar sobre frío la velocidad como un arma de desarrollo.

Para optimizar el trabajo con los Story Points el equipo debe tomar un ítem del Backlog, discutirlo brevemente y formular mentalmente una estimación. Entonces todos sostienen una tarjeta con el número que refleja su estimación. Si todos están de acuerdo procederán con los siguientes pasos, si no, deberan tomarse un tiempo (pero no demasiado) para entender la razón del desacuerdo surgido en cierta estimación. Es importante recordar que la estimación debe ser una actividad de alto nivel. Si el equipo está en mala vibra, bajo presión, malhumorado o desanimado es mejor tomarse un descanso y volver cuando se puedan asegurar estimaciones precisas y bien formuladas.

Es importante recordar que la estimación debe ser una actividad de alto nivel. Si el equipo está en mala vibra, bajo presión, malhumorado o desanimado es mejor tomarse un descanso y volver cuando se puedan asegurar estimaciones precisas y bien formuladas.

Estimen con Inteligencia, no bajo presión

Ninguna tarea debe tomarse más de 16 horas de trabajo. Si estás usando Story Points, puedes decidir que 20 puntos es el límite. Es muy difícil estimar el trabajo con una medida más grande que esa con confianza. La confianza es especialmente importante para cada ítem porque el Product Manager debe asegurar la consecución exitosa de los tiempos estimados. Cuando se estima algo por encima del umbral de 16 horas (o 20 puntos) es una señal para dividirlo en partes más pequeñas y reestimar. No pierda el tiempo estimando el trabajo si es probable que cambie en un futuro. Es opcional en estos casos dar al Product Manager una medida aproximada que pueda utilizar para dar prioridad al backlog del producto apropiadamente.

Aprendan de las estimaciones pasadas

El Feedback que se obtiene de estimaciones pasadas hechas por el equipo pueden enseñarte muchísimo tanto si eres Product Manager o si eres integrante del equipo de ingenieros o de desarrollo. Muchas herramientas ágiles como JIRA, Trello, Asanna, etc que permiten rastrear los Story Points, lo que hace que el Feedback de las estimaciones sean mucho más preciso y fácil de realizar. Intente, por ejemplo, sacar las últimas 5 historias de usuario que el equipo entregó. Analice si cada uno de esos ítems de trabajo tenía un nivel similar de esfuerzo. Si no es así, discuta por qué. Utilice esa visión en futuras discusiones de estimación.

Como todo lo demás en ágil, la estimación es una práctica. Adquirimos más conocimientos mientras más estimamos así que es necesario tomar todos los factores comentados en el post.

Tienes alguna sugerencia o tip que podamos usar para realizar mejores estimaciones en la metodología ágil?