Las estimaciones en proyectos ágiles, al igual que en cualquier tipo de proyecto, son eso: ¡estimaciones!

Hacer estimaciones acertadas es difícil, especialmente en trabajos innovativos y con alto grado de incertidumbre.

Cada proyecto es único y diferente a los demás en cuanto a los objetivos que se propone, el equipo que lo conforma, el cliente, el contexto y otra gran cantidad de parámetros que lo influyen. En ciertos casos, los estimadores son muy optimistas y subestiman los problemas a simple vista, pero luego la realidad muestra que no lo eran. La tecnología involucra complejidades y normalmente surgen imprevistos que generan demoras en los trabajos.

Es difícil estimar un valor exacto del tiempo necesario para desarrollar una historia de usuario, y más aún cuando no se cuenta con un considerado nivel de detalle del requisito.

Ese es el motivo por el que los equipos ágiles generalmente realizan estimaciones con valores relativos y no absolutos.

El Proceso de Estimación

El primer paso en la estimación y planificación ágil es la creación de la lista de trabajo pendiente del producto o pila de producto (Product Backlog) con los requisitos que determinan las características del producto que se desea realizar.

Los elementos de la lista de trabajo pendiente del producto se suelen expresar en formato de historias de usuario, aunque también podrían tener otro tipo de formato, y expresan las funcionalidades y los requisitos del negocio que se deben considerar en el proyecto.

Justamente, una historia de usuario es un requisito de negocio visto desde el punto de vista de un usuario.

Las historias de usuario deben redactarse claramente, ser factibles de realizarse y poder verificarse o probarse.

Cuando la historia de usuario es muy grande e involucra muchas características se denomina Épica (Epic). Una Épica es una historia de usuario de alta granularidad que puede subdividirse en historias de usuario más pequeñas.

Al inicio de la planificación, se suele partir de grandes historias o Épicas para luego, a medida que se obtiene más información sobre las necesidades del cliente, ir dividiéndolas en historias más pequeñas, con mayor nivel de detalle.

La estimación del esfuerzo que llevaría elaborar el requisito de negocio definido por cada historia de usuario se realiza asignándole un número de puntos de historia (Story Points). Estos puntos de historia son valores arbitrarios que, de alguna manera, definen el tamaño y la complejidad de la historia de usuario, en cuanto al esfuerzo necesario para desarrollar, ejecutar y completar el requisito.

Los puntos de historia no representan horas, días ni ninguna referencia al tiempo, sino que son valores que toman significado sólo cuando se comparan entre sí, siendo los valores más altos los correspondientes a mayor tamaño y complejidad.

Para definir los puntos que se asigna a cada historia de usuario, se comparan las historias entre sí. Esta estimación no es de valores absolutos, sino que es una estimación relativa.

La forma de estimación parte de asignarle a las historias más simples un valor unitario (1), mientras que a las historias de mayor tamaño y más complejas se les va asignando números mayores, por comparación con las primeras.

En general, los equipos ágiles utilizan los valores de la serie de Fibonacci para asignar los valores de los puntos de historia.

La serie de Fibonacci comienza con los números son 1 y 2 y a continuación, cada número se obtiene sumando los dos anteriores, de tal forma que la secuencia queda: 1, 2, 3, 5, 8, 13, 21, 34, 55….

Una variante de la serie de Fibonacci es la escala de Cohn, denominada así por su autor, Mike Cohn. Esta escala utiliza la secuencia: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100.

Otra serie que se suele utilizar es la progresión geométrica de razón 2, que comienza con 1 y luego cada número se obtiene con la multiplicación del número anterior por la razón, es decir, 2. Esta serie comienza con la siguiente secuencia: 1, 2, 4, 8, 16, 32, …

Para realizar las estimaciones, el equipo de desarrollo, en conjunto, analiza las historias de usuario y asigna los puntos de historia por consenso.

Utilizar intervalos de estimación apropiada

Al usar las series mencionadas, las estimaciones no son puntuales, sino que se estima un intervalo. Por ejemplo, usando la serie Fibonacci, no se podría estimar una cantidad de 6 puntos de historia, sino que se debe elegir entre 5 y 8.  El equipo debe decidir si el tamaño de la historia de usuario estaría más cerca del 5 que del 8.

Esto facilita llegar al consenso en el equipo y lo hace algo más realista. Igualmente, sigue siendo una estimación.

Por otro lado, los mismos clientes y equipos impactan en el tiempo que lleva realizar los trabajos. Los conocimientos, experiencias y habilidades de los integrantes del equipo impactan directamente en la velocidad del equipo. Los clientes y las organizaciones tienen sus propias expectativas, intereses y su actitud ante los riesgos, que pueden facilitar o restringir el avance del proyecto en la velocidad estimada.

Estas estimaciones sirven para proporcionar una idea del esfuerzo y del tiempo necesario para entregar el proyecto. Solo una idea. Generar los compromisos de entrega sobre estas estimaciones puede generar conflictos en el proyecto.

Lo más probable es que se tenga una estimación más certera sobre las fechas de entrega cuando el proyecto esté llegando a su conclusión, sobre todo en los entornos de alta incertidumbre como lo son los proyectos ágiles.

Es esa la razón por la que los enfoques ágiles establecen intervalos fijos de trabajo, como lo son las iteraciones o sprints, e incluso muchas veces se establece la cantidad de iteraciones que se llevará a cabo en el proyecto. En este caso, la variable que se modifica es el alcance del proyecto, es decir, la cantidad de facilidades, características y requisitos en historias de usuario que se completarán en ese tiempo.

Dado que las historias de usuario se priorizan continuamente para aportar el mayor valor al negocio en el menor tiempo posible, quedarán fuera del proyecto, pendientes para proyectos futuros, aquellas historias de menor prioridad.

Otro aspecto importante en la planificación de proyectos ágiles se centra en la decisión de la duración de cada iteración. Se recomienda que las iteraciones tengan una duración máxima de 6 semanas, preferentemente no superando las 4 semanas.

Dado que cada iteración representa una oportunidad para entregar valor al negocio, obtener retroalimentación de parte del cliente, aprender y volver a planificar, adoptar una duración de iteración muy extensa, disminuye estas posibilidades.

En contrapartida, se debe recordar que en cada iteración se debe elaborar un producto incremental que provea valor al negocio, y ello requiere cierto tiempo.

Encontrar el equilibrio es uno de los desafíos de los equipos ágiles. No hay una norma establecida, sin embargo, las recomendaciones apuntan a tomar iteraciones más cortas cuando la incertidumbre y la volatilidad de los requisitos sea mayor para tener mayor interacción con los interesados y aprender más rápido, “equivocarse rápido”, como suelen decir los agilistas.

Autora: Cecilia Boggi

Cecilia Boggi es fundadora y Directora de activePMO, enfocada en consultoría y capacitación en liderazgo de proyectos tradicionales y ágiles. Licenciada en Análisis de Sistemas, Doctora en Administración de Empresas y executive MBA, posee varias certificaciones profesionales y gran experiencia en tecnologías de la información, mejoras de procesos e implementación de Oficinas de Gestión de Proyectos (PMO). Expositora en Congresos internacionales, autora de libros y artículos de liderazgo y dirección de proyectos.