¿Cómo medir el avance y éxito de proyectos usando Scrum?

Una de las grandes diferencias entre la gestión de proyectos en cascada y las de control de procesos empírico, como Scrum, es la forma en la que medimos el progreso y el éxito del proyecto. Toda organización se beneficia al saber los resultados obtenidos de una inversión, sin embargo el Product Owner (PO) no siempre conoce que información es relevante para cada parte interesada.

Para el Project Manager tradicional, para efectos comparativos, medir el progreso es: seguir el plan y medir el porcentaje de completitud desde el inicio hasta el fin del proyecto. Al llegar a la fecha final se puede decir si se cumplió un 100% del plan o si es necesario más tiempo o recursos para lograr el alcance definido. Esta forma de medición no es apta para proyectos ágiles, no solo no va a ser significativa en cuanto al avance real, sino que trabajar de esta forma puede llegar a ser un factor de riesgo importante de fracaso del proyecto.

Si intentamos medir el avance del proyecto basándonos en el plan inicial, nos arriesgamos a posicionar al PO bajo presión innecesaria por dar seguimiento a requerimientos que dejan de ser relevantes, de manera que bajo esta situación se tiende a dar más relevancia a los requerimientos del plan inicial sobre los de mayor valor detectados en el camino. Esto se traduce a grandes perdidas financieras para la organización.

El manifiesto ágil presenta la regla de oro de las mediciones de avance: "el software que funciona es la principal medida de progreso". La propuesta Scrum es la de enfocarnos en la visión y objetivos de negocio: aumentar los leads de un sitio en un 10%, mejorar el ciclo de proceso en un 15%, reducir la cantidad de incidencias en un 50%, etc. Dejar el "cómo" (Backlog) al equipo Scrum, y que ese plan vaya madurando con la retroalimentación de los usuarios y partes interesadas a través de todo el proyecto de entrega progresiva. Esto es lo que quiere decir que el Backlog nunca está completo y que es un artefacto "vivo" que evoluciona conforme más se conoce de los usuarios y del entorno del producto, incluso en etapas tardías del desarrollo.

Entonces el progreso no se mide con el delta del plan inicial vs. el actual, sino con la entrega incremental de software que funciona y las consecuencias de dichos incrementos de producto, a través del tiempo, en su entorno. El resultado a medir depende de la naturaleza del producto y es responsabilidad del PO el traducir las metas de negocio al equipo y presentar los resultados de los entregables a las partes interesadas. 

Un ejemplo práctico es: si una meta de negocio es aumentar el número de leads de un sitio, estos son, en síntesis, los pasos a seguir por el PO y el equipo:

1. El PO mide la cantidad de leads del sitio y las tendencias, antes de tomar cualquier acción.
2. El PO crea los elementos del backlog que considera necesarios para lograr el objetivo. Esto puede basarse en su experiencia, estudios de mercado, asesorías, etc.
3. El PO se reúne con las partes involucradas para proponer su hipótesis y crear otros requerimientos que puedan servir al objetivo.
4. El PO se reúne con el equipo de desarrollo para refinar, priorizar y estimar los elementos del Backlog. Puede ser que el equipo tenga ideas adicionales a ser agregadas/modificadas en el Backlog.
5. Al seguir el flujo del marco de trabajo, cuando se encuentren desarrollados los requerimientos y el PO decide lanzarlos a producción, el PO se encarga de medir la nueva tendencia de los leads del sitio, para comprobar si las acciones tomadas tienen el efecto deseado.

En el ejemplo anterior, la métrica más importante de éxito es el incremento del número de leads del sitio basado en tendencia, de antes y después de implementados los cambios. 

Un error común al intentar dar seguimiento a proyectos Scrum, es utilizar los Story Points como medida de progreso. Esto puede llevar a una falsa sensación de avance, o el contrario, una falsa percepción de no-avance lo cual tiende a desmotivar al equipo y ejerce presión de generar una mayor cantidad de puntos por Sprint. Cuando esto sucede generalmente se sacrifica la calidad y disminuye el compromiso del equipo; la situación empeora aún más si se intenta medir la productividad por Story Points quemados por desarrolladores individuales, esto último sacrifica al trabajo en equipo y la motivación.

En el ejemplo anterior, ¿Que sucede si se entregan 50 Story Points en un Sprint, pero el software que se lanzó a producción no generó un cambio cuantitativo en cuanto al objetivo de negocio, que en este caso era un aumento en la tendencia de leads? La respuesta es que, al menos en ese Sprint, no se logró el objetivo de negocio aunque el equipo haya completado todas las tareas y todos los Story Points. Es por eso que el PO debe de tener el conocimiento de negocio necesario para saber la correlación entre una lista determinada de elementos del Backlog y un objetivo de negocio; es decir, conocimiento del impacto en el entorno del producto sobre la entrega de una funcionalidad.

La velocidad del equipo en Story Points únicamente debe de servir como medida del equipo de desarrollo para pronosticar la carga de trabajo que es capaz de realizar en un Sprint y para que el PO pueda proyectar lanzamientos en el tiempo para la toma de decisiones; aunque generalmente este ultimo es un pronóstico con riesgo, sirve para priorizar y definir fechas de negocio (capacitaciones, campañas publicitarias, etc).

En conclusión, hay métricas para medir la productividad que el equipo puede utilizar para planificar y mejorar en cada iteración, como los Story Points; pero estas no son para medir el ROI. Por otro lado, las métricas para determinar el éxito del proyecto varían dependiendo de la naturaleza del mismo (mejoras en ciclos de proceso, reducción de gastos, mejora de experiencia de usuario, retención de clientes, etc.) Por lo que es responsabilidad del PO, primero el transferir los objetivos de negocio al equipo de desarrollo, y segundo medir el antes y después de logrado cada objetivo para así poder demostrar los resultados del proyecto.

Me atrevería a decir que un proyecto ágil exitoso no es aquel que entrega lo planteado inicialmente a tiempo, sino el que logra los objetivos de negocio hacia una visión estratégica organizacional y cuyo resultado justifica la inversión realizada.

¿Qué opinas al respecto? Estoy seguro que faltan muchos temas por abarcar que a mucha gente nos puede servir de ayuda en nuestros proyectos.