En un artículo publicado en el IEE , los autores, defienden que se puede adaptar el Método del Valor Ganado a proyectos realizados mediante enfoques ágiles (lo que denominan Agile EVM) demostrando matemáticamente la relación entre las unidades de medida del EVM y las métricas ágiles usadas en Scrum (Sulaiman T. et al., 2006).
Aunque esta asunción matemática, sólo se valida en su investigación para proyectos bajo la implementación Scrum, los propios autores asumen que se pueden derivar sus conclusiones a cualquier enfoque ágil de gestión de proyectos, siempre que se respeten los siguientes aspectos en la implementación ágil elegida:
Organización de pequeños equipos de trabajo
Producción de frecuentes incrementos de trabajo que puedan ser aceptados por el cliente
Pruebas y documentación constante a lo largo de todo el proyecto
La posibilidad de dar por concluido el proyecto en cualquier momento que sea necesario (porque se haya consumido el tiempo requerido, porque se haya alcanzado la funcionalidad deseada)
5.2.1 Implementación estudiada de Agile EVM
Además, los autores (Sulaiman T. et al., 2006), hacen una acotación adicional, se concentran en la medición del proyecto a nivel de release (o entrega formal del proyecto, validada ya de tal forma, que pueda entrar en producción, como un mínimo producto viable) en vez de hacerlo en cada sprint, o incluso a nivel global del proyecto.
Asumen que un buen ejemplo de esta limitación, puede ser que cada sprint del proyecto, tenga una release que directamente pueda entrar en producción, obviando así cualquier otro enfoque y manteniendo el foco de la investigación en el seguimiento de cada una de las iteraciones que conlleven la entrada de nueva funcionalidad en el entorno productivo.
Para ello, tratan de medir el progreso real al final de cada sprint con la velocidad actual del sprint y los costes ya conocidos.
Para ello, hacen la siguiente traslación entre conceptos del enfoque EVM a su enfoque Agile EVM:
Línea Base del Proyecto (alcance)
En la primera igualdad, igualan el alcance total del proyecto (medido en horas hombres, así como en la duración total del mismo en el Método tradicional, con el número de puntos historia planificados para una release en concreto).
Línea Base del Proyecto (Duración)
Del mismo modo, para obtener el calendario de la línea base del proyecto, trasladan el calendario tradicional del Método, al número total de sprints y la duración de cada uno de ellos, que siguiendo el enfoque Scrum, ambas magnitudes serán fijas a lo largo del proyecto.
Línea Base del Proyecto (Presupuesto)
Para obtener la estimación del presupuesto consumido a la finalización del proyecto, simplemente lo acotan al presupuesto consumido a la finalización de la release.
Avance del Proyecto (I)
Para realizar el seguimiento del estado actual planificado del proyecto, igualan la medición tradicional del progreso a la fecha actual, con la división del número del sprint entre el número total de sprints planificados para la release. Nótese que en Scrum, el alcance no está fijado de antemano y que bajo este enfoque, el progreso actual, se centra en el tiempo consumido (en porcentaje) del total de tiempo planificado para la release.
Avance del Proyecto (II)
Para realizar el estado del estado actual del proyecto, igualan el concepto tradicional de valor ganado (medido en unidades monetarias) con el número de puntos historia completados hasta la fecha, sobre el total de puntos historia planificados para la release. Nótese otra vez, que siguiendo el enfoque ágil Scrum, no todos los puntos historia podrían ser realizados, dado que el criterio que es fijo en el proyecto es la duración y los recursos (presupuesto) y no el alcance. Del mismo modo, asumen unos valores iniciales que sirvan de referencia para el proyecto, como se puede ver en la tabla siguiente:
Valores fijos siguiendo prácticas Scrum puras (I)
Siguiendo esta técnica, al final de cada sprint, calculan cuatro métricas que asumen suficientes para el cálculo siguiendo su implementación del Método del Valor Ganado Ágil:
Valores fijos siguiendo prácticas Scrum puras (II)
Para realizar cualquier cálculo sobre el valor ganado (bien el real actualmente, bien el planificado o esperado futuro), necesitan obtener de alguna forma el Percent Complete (PC) de la técnica tradicional del Método del Valor Ganado.
Por ello, basándose en el trabajo de Mike Cohn (Cohn M., 2011), asumen que las historias de usuario representa fielmente el esfuerzo del proyecto, asunción que ven reforzada si existen requisitos que pueden ser fácilmente probados y aceptados por el Product Owner (Cockburn A., 2005)
5.2.2 Demostración matemática de la validez del Agile EVM
La hipótesis que utilizan para demostrar la validez de su enfoque es que si el coste final previsto del proyecto (EAC) que proporciona el EVM se puede aproximar a la velocidad media de Scrum, entonces las técnicas de EVM pueden ser usadas bajo un enfoque ágil con las mismas garantías que en un proyecto gestionado mediante un enfoque predictivo.
Una vez demostrado esta hipótesis mediante fórmulas matemáticas, disponibles en el estudio los autores se preguntan la validez de sus conclusiones mediante tres preguntas.
5.2.2.1 ¿Son las métricas válidas para proyectos Scrum?
En sus conclusiones, citan textualmente:
Además, añaden que estas conclusiones han sido validadas en dos proyectos de forma empírica.
Assuming that the burndown trend analysis is valid for Agile projects, we have shown mathematically that the calculations for Release date using Estimate At Complete and calculations for Release date using the burndown trend analysis are the same.
5.2.2.2 ¿Añaden un esfuerzo de gestión adicional en el proyecto?
Mediante la confirmación del equipo de proyecto que ha participado en la medición real de los proyectos objeto de la validación empírica, asumen que no representa un esfuerzo adicional en la gestión del proyecto.
5.2.2.3 ¿Es de utilidad real la medición que hacen para todos los stakeholders?
Los autores asumen que las métricas ágiles ya son conocidas por el equipo de proyecto (aunque sorprendentemente sólo citan al Scrum Master, lo que casa bien poco con el enfoque de equipos planes, auto gestionados y comprometidos de forma responsable con el proyecto). Añaden, que la estimación de coste final (EAC) planteada será muy útil para los stakeholders que tengan que hacer decisiones relativas al presupuesto del proyecto, y por tanto, estén involucrados en el ROI del mismo.