En mi modesta opinión, me parece una buena recopilación de métricas (algunas difíciles de automatizar, como la del resultado de las retrospectivas, pero no por ello de menor valor. Me atrevo a preguntaros, ¿qué 5, 6 ó 7 métricas usarías para que el cliente tuviera una visión resumida del estado del proyecto? Vamos, ¿cómo construiríais el “cuadro de mandos” para vuestros clientes?

Vale, como está feo tirar la piedra y esconder la mano, ahí van las mías:

• Velocidad del equipo (para cada sprint)
• ROI. Cada historia de usuario debe tener un valor de negocio asignada por el Dueño del Producto y, por tanto, podemos saber cuánto valor de negocio se ha convertido en cada sprint.
• Las tres métricas de calidad que Xavi resalta: Satisfacción del cliente o usuario, Incidencias o defectos detectados por los usuarios, Defectos detectados por el equipo de desarrollo.
• Tiempo de puesta en producción después de cada sprint. (Esta métrica no la incluye Xavi, pero a mi entender serviría para, de alguna manera medir parte de las “Lecciones aprendidas”)

Me gustaría también ser capaz de ofrecer al cliente alguna medida del riesgo que se está asumiendo y cómo va afectando éste durante la vida del proyecto, pero sinceramente no sabría bien cómo hacerlo. Quizás una buena referencia para esto (en inglés) sería este artículo que enseña a estimar el riesgo con una hoja de cálculo.

No estaría mal mostrar el “panel de control” como una “radar chart” para poder comparar de un vistazo varias métricas de un sprint a otro, p.ej.

¿Sería diferente el cuadro de mandos del cliente y el del ScrumMaster o jefe de proyecto? Hombre, el corazón me dice que deberían ser iguales por eso de que “somos un equipo”, “la transparencia con el cliente”, y todo eso…, pero la razón me dice que a cada uno le interesa una perspectiva diferente del proyecto:

• al cliente es algo más económico, de valor de negocio, de rentabilidad de la inversión en marcha,
• mientras que al ScrumMaster le interesa más bien los impedimentos que se pueden estar acercando para poderse adelantar a su aparición.

Por eso creo que deben ser diferentes. ¿Cuáles serían vuestras métricas para el ScrumMaster?

Las mías, creo que serían:

• Velocidad del equipo. Sí, también, de hecho, con más razón incluso que para el cliente. De esta métrica se pueden sacar muchas conclusiones que contrastar en las retrospectivas con el equipo. Es muy importante averiguar a qué pueden ser debidas las variaciones en la velocidad: estimamos mejor, hemos eliminado un impedimento que puede volver a surgir, ha surgido un impedimento que nos retrasa…
• Las líneas de código. Sí, sé que es un poco llamativo y
  “anticuado”, pero me parapeto detrás de un excelente artículo de James
  Shore (autor de “The Art of Agile Development”) sobre cómo medir la deuda técnica.
• Felicidad del equipo. Bfff, esto es dificil de explicar, pero la actitud que tiene el equipo después de cada retrospectiva es importantísimo en el desarrollo del siguiente sprint. Recomiendo leer sobre el “Niko-niko calendar“, y si alguien lo pone en práctica, estaría encantado de conocer sus impresiones.
• Desviación en las estimaciones. Me parece importante ofrecer este feedback al equipo (porque el “cuadro de mandos” creo que debe ser para todo el equipo), y por ello creo que el ScrumMaster debe ser capaz de recopilar esta información y manejarla con cuidado porque puede afectar mucho a la credibilidad del equipo (incluso para ellos mismos).
• Calidad del código: cobertura, complejidad ciclomática y las reglas de calidad acordadas que podamos automatizar con herramientas como Checkstyle, PMD, JDepend… Para esto último aconsejo encarecidamente que probéis Sonar.

Algunas métricas (como el “nikocal”) no son exactamente cuantificables, pero no es importante porque de lo que se trata es de ver las tendencias. En todos los casos, lo que importa no es la “instantánea” sino la tendencia puesto que sólo de las tendencias podemos sacar conclusiones o al menos elaborar hipótesis que nos ayuden en nuestro camino.

Doy por supuesto que tenemos en las paredes o en una herramienta (como radiadores de información) nuestros paneles constantemente actualizados con las historias de usuario del sprint en curso, las iniciadas y las terminadas, así como el gráfico de “burndown” y cualquier otro que vuestro(s) equipo(s) haya(n) considerado a bien tener siempre a la vista.

Y también doy por supuesto que nuestro equipo y nuestra organización están ya lo suficientemente maduros como para no tener que medir cosas como:

• Número de veces que se rompe el build (en Integración Continua)
• Calidad de los commits en el SCM. Por ejemplo, si pasan días sin que nadie haga commit es que algo muy malo está pasando. O si los commits no llevan un comentario que permita identificarlo y trazarlo con la tarea correspondiente.