Cálculo del SPI en un Proyecto Ágil

Una de las preguntas más frecuentes que se hacen quienes comienzan a trabajar en el mundo de la agilidad es, ¿cómo calculo el avance de la construcción de mi producto?, en este post quiero compartir como es posible hacerlo.

Vamos a comenzar con poner los equivalentes del método del valor ganado (1)(2) en un proyecto agil:

• Valor :
• funcionalidad puesta a disposición del cliente que le reemplaza una existente o le mejora su negocio,
• Generalmente medida en puntos en proyectos ágiles, 
• Las funcionalidades inicialmente construidas tienen mayor valor de negocio que las construidas al final debido a la priorización del backlog  (3). El valor de negocio es subjetivo y es dado por el Cliente y/o Product Owner en Scrum (3)
• Punto: 
• Percepción (debido a la incertidumbre) del esfuerzo requerido para construir una funcionalidad
• Por lo general se usa la serie de fibonacci alterada para "tallar" (poner talla), estimar una funcionalidad (historia de usuario, caso de uso) a ser construida, La serie usada es 1,2,3,5,8,10,20
• BAC 
• Presupuesto a la terminación del proyecto. Budget at Completion
• En ágil emplearemos como BAC la cantidad de puntos estimados del release
• EV
• Valor ganado del proyecto
• En ágil emplearemos la cantidad de puntos en DONE (5) al momento de hacer la medición
• PV
• Valor planeado
• En ágil emplearemos la cantidad de puntos  planeados en DONE al momento de hacer la medición.
• El insumo de los puntos planeados en Done es proporcionado por la gráfica del Burn Up Release
• Release Burn Up
• Gráfica empleada en proyectos ágiles en la cual en el eje "x" se encuentran los Sprints, en el eje "y" los puntos acumulados. De igual forma se gráfica la cantidad de puntos estimados que tendrá el release (como techo del mismo) y en el tiempo se presentan los puntos acumulados sprint tras sprint, en aras de buscar una tendencia y un estimado para lograr el posible despliegue de una versión liberable.
• SPI
• Indice de desempeño del cronograma
• Indica la proporción en la que se cumple el planeado a la fecha 
• si es mayor que 1 se encuentra el proyecto adelantado vs el planeado
• si es menor que 1 se encuentra el proyecto atrasado vs el planeado

Dado estos insumos los cálculos de los índices son:

• Avance = EV / BAC = Puntos en Done al momento de la medición/ Puntos totales del  Release

• SPI = EV / PV = Puntos en Done al momento de la medición / Puntos proyectados

Condiciones, Restricciones y Aclaraciones
Es importante aclarar que en un proyecto ágil pueden darse las siguientes condiciones:

• Si se alcanza valor de negocio más temprano se puede parar la construcción de este release y comenzar el siguiente
• Si existe una fecha límite se le puede ofrecer al cliente:
• dado que el equipo tiene una velocidad (tasa a la cual produce software sprint tras sprint) que funcionalidades desea sacar del product backlog para cumplir la fecha impuesta
• cuales funcionalidades cumplen el objetivo de negocio que quiere resolver con la solución
• Dada la incertidumbre inherente al desarrollo de software (clic aquí), muchas veces se puede contestar:
• esa capacidad de negocio la logramos aproximadamente entre el sprint 7 y 10, en función de la priorización del backlog

Espero haber aportado/ayudado a la solución de esta inquietud frecuente.

Saludos Ágiles

Jorge Abad

Post relacionados:

1. EVM, CPI, SPI en AGILE / SCRUM - clic aquí -.
2. Diferencia entre Valor de Negocio (Ágil) y Valor según el PMI - clic aquí -.
3. Mi versión de : SCRUM EN POCAS PALABRAS / SCRUM RESUMIDO - clic aquí -.
4. Planning poker  - clic aqui -.
5. Una versión inicial de Definition of Done (Definición de Hecho / Terminado / Realizado) - clic aquí -.

Diferencia entre Valor de Negocio (Ágil) y Valor según el PMI

Una de las técnicas que tiene el PMI en el PMBoK para hacer seguimiento del avance del proyectos es la Técnica del Valor Ganado (earned value method  -EVM -) y esta consiste (de una forma muy básica) determinar cuanto alcance hemos logrado con respecto la linea base planteada de costos, o sea:

• Imaginémonos un proyecto donde planteamos que al 75% del tiempo del proyecto, el valor del alcance logrado era de $100.000.0000, pero si para esa fecha el valor de alcance logrado es de $60.000.000, este último valor corresponde al VALOR GANADO a la fecha..

Lo triste es que si con  estos $60.000.000 y 75% del tiempo del cronograma  el equipo del proyecto se la pasó haciendo:

• documentación, 
• prototipos, 
• tablas paramétricas
• funcionalidades que no correspondían al core del negocio, 

Lo que hicieron pudo pudo haber sido "muy bueno - funcionar muy bien - ", "muy bonito" pero sino lograron avanzar en lo realmente importante de poco o  nada sirve.  (se cancela el proyecto por alguna razón externa extraña y ese tiempo y dinero invertido no aportaron a su propósito dentro del negocio del cliente)

En las metodologías ágiles nos enfocamos en el valor de negocio, o sea en las funcionalidades que permiten al cliente poner a funcionar su negocio lo antes posible (buscando cumplir siempre con el principio de pareto : 20% de las funcionalidades que aportan al 80% del negocio), documentando solamente lo realmente importante y aplazando funcionalidades:

• nice to have (seria lindo / chévere que hiciera..)
• o ya que...
• "ya que" estamos haciendo esto.. hagamos aquello
• que solo van a hacer usadas por una persona cada año (o similar) y que se obtienen con query a base de datos
• Programar casos que en el proceso de negocio nunca se presentarán o que se resuelven diciendo "el sistema no soporta esta funcionalidad." o si se dá el caso miraremos si lo hacemos en una próxima versión.
• que emulan al excel, perfectamente pudiendo exportar a excel y allí realizar el tratamiento de datos adecuado (he visto muchos sistemas así.. ¿¿¿ustedes no??? )

Por lo tanto VALOR DE NEGOCIO y VALOR según el PMI son distintos.

Y lo que sería más sensato llamar a la técnica del valor ganado(EVM), mejor como "TÉCNICA ALCANCE COMPRADO/LOGRADO", pues quizás ese alcance comprado/logrado sea o no sea de valor para el negocio y los índices de avance SPI, Y CPI servirán para determinar cuanto estamos cumpliendo con el plan, pero no realmente cuanto valor estamos generando para nuestro cliente.


Nota:
Para una mayor precisión sobre el tema sugiero leer el Chaos Manifesto del 2013, del Standish Group( http://versionone.com/assets/img/files/ChaosManifesto2013.pdf ) el cual cito textualmente:  "Our analysis suggests that 20% of features are used often and 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently. The task of requirements gathering, selecting, and implementing is the most difficult in developing custom applications. In summary, there is no doubt that focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. After all, there is never enough time or money to do everything. The natural expectation is for executives and stakeholders to want it all and want it all now. Therefore, reducing scope and not doing 100% of the features and functions is not only a valid strategy, but a prudent one. "

EVM, CPI, SPI en AGILE / SCRUM

En el mundo Agile / Ágil he notado tres tendencias:

1. Los que buscan la optimiización, la eficiencia, el ROI, (tipo Jeff Sutterland)
2. Los que son extremadamente poéticos, que nos les gusta que les hablen de puntos de historia, de horas, de eficiencia, solo de valor como un bien tangible de una manera sobrenatural para el PO (Product Owner)
3. y los que están /estamos (me incluyo) en la mitad de las corrientes, que creemos que primero están las personas e interacciones que los procesos y herramientas (como lo promulga el manifiesto ágil, - clic aquí), pero que aún así les interesan los índices las métricas para mejorar predictibilidad y lograr equipos más felices y más profesionales.

Este articulo no le gustará a los segundos, los otros dos lo recibirán con agrado. No voy a satanizar ni a exaltar a ninguna de estas tres corrientes, lo que si he comprendido es que cada equipo encuentra las métricas que le ayudan a autogestionarse y a saber si llegan a la meta, a concretar la visión. 

Dentro del  amplio espectro de métricas posibles, y con la necesidad de tener herramientas para medir el avance de parte del PO basados en los lineamientos del PMBOK, hace unos días me encontré con este PDF de Collabnet AgileEVM  clic aquí, donde se explica como calcular el valor del SPI, CPI para proyectos ágiles. A continuación realizaré mi propio ejemplo basado en esta propuesta:

Puntos estimados para el proyecto	250
BAC (budget At Completion) Presupuesto estimado del proyecto)	$ 130.000.000
Puntos totales hasta el momento	60
Porcentaje completado Puntos totales hasta el momento / Puntos estimados del proyecto	24%
Sprints planeados	5
Sprints completados hasta el momento	2
Porcentaje pleneado completado Sprints completados hasta el momento / sprints planeados	40%
PV (valor planeado) BAC (2)x Porcentaje planeado completado	$ 52.000.000
EV (Valor ganado) BAC x Porcentaje completado	$ 31.200.000
AC (costo actual del producto) Total desembolsado, facturado, o pagado por el producto	$ 43.000.000
CPI = EV/AC índice de desempeño del costo. Esto se interpreta que por $100 que se invierten solo $72,56 se convierten en valor para el producto	72,56%
SPI= EV / PV índice de desempeño del cronograma. Esto se interpreta como, que tenemos un atraso del 40% respecto a lo que deberíamos estar hoy.	60,00%
EAC  (costo estimado final del proyecto - estimate at completion ) Forma de cálculo 1 - supone similar comportamiento del proyecto EAC = BAC / CPI	$ 179.166.667
EAC  (costo estimado final del proyecto - estimate at completion ) Forma de cálculo 2 - se usa cuando la situación actual es atípica respecto al futuro, y creemos que la situación se corrige EAC = AC + BAC – EV	$ 141.800.000
EAC  (costo estimado final del proyecto - estimate at completion ) Forma de calculo 3 - se usa cuando se supone un mal rendimiento del costo así como la necesidad de establecer una fecha de conclusión inamovible EAC = AC + [(BAC – EV) / (CPI acumulativo x SPI acumulativo)].	$ 269.944.444

Es importante tener en cuenta que todas estas son proyecciones que ayudan a saber como esta la salud de la construcción del producto respecto a un plan inicial el cual es una aproximación, una estimación y no un compromiso.

Pero si resulta por ejemplo, que se encuentra valor de negocio en el Sprint 3 (por un costo de $22.000.000) y se decide NO seguir construyendo, crear un Release y salir a producción,  pues se alcanzó el objetivo que se quería con el proyecto, el costo del proyecto es menor ($65.000.000) y  se puede tener un ROI mucho más temprano que bajo el esquema de trabajo tradicional que por lo general solo contempla la finalización del producto cuando se alcanza todo el proyecto con su alcance pactado.

Saludos Ágiles

Jorge Abad