Una vez que nuestros clientes finalizan nuestros Talleres de Scrum, el reto más común que encuentran es cómo rastrear el éxito de la implementación de Scrum en la organización.
Cuando iniciamos la tarea de escalar Scrum a nivel organizacional, nos es muy útil la información irradiada de diferentes indicadores que vigilan cómo el valor del software se está entregando en todos los equipos Scrum.
La constante vigilancia e interpretación de esos indicadores en la forma de métricas es similar, en palabras de Jeff Sutherland, a volar un avión de caza de quinta generación mientras se leen la enorme cantidad de sensores. La integración irradiada por los sensores es continuamente integrada por los procesadores del avión y por el cerebro del piloto.
Intimidante ¿no? Aunque puede serlo al principio, el éxito de un piloto consiste en interpretar toda esa información y tomar las acciones correspondientes para cumplir la misión. Nótese que gran parte del trabajo del piloto es responder a sus indicadores de vuelo más que cambiar las lecturas que recibe, las lecturas provienen de sensores.
En la implementación de Scrum, las métricas no son un objetivo en sí mismas y están basadas totalmente en ver desde diferentes ángulos la pregunta: "¿Estamos mejorando nuestra entrega de valor?".
Scott Downey ha publicado un conjunto de métricas para Scrum que considero merecedoras de consideración. El material de Scott puede encontrarse aquí.
Con el fin de explicar las métricas que propone Scott, estableceré un escenario concreto sobre el cual explicar cada métrica.
Algunas de las métricas no se pueden entender separadas de las demás, por lo que debemos que integrar todas las métricas para entender lo que está pasando en los equipos de la organización.
Un detalle delicado de varias de éstas métricas es que usan el esfuerzo real que requirió un User Story contra el estimado. El ir rastreando el esfuerzo real es un gasto general más sobre el proceso por lo que sugiero precaución en el sentido de no descuidar el proceso entero de adopción, cuidado del equipo y entrega de valor debido a que se introduce más costos. Scott sugiere que durante los Scrums diarios se le pregunte al equipo cuántos Story Points el equipo le dedico durante el día anterior a cada User Story de manera que así se rastree los Story Points reales diariamente.
Por otra parte, se obtiene mucho entendimiento de lo que está pasando en la organización cuando se mantiene un histórico de éstas métricas y se analiza su comportamiento Sprint tras Sprint.
Story Points
Las estimaciones que veremos a lo largo de este artículo usan Story Points. La estimación en Story Points se basa en la técnica orignada por Barry Boehm y John A. Farquhar llamada Wide Band Delphi.
En este otro artículo examino porqué estimar en Story Points usando Planning Poker es mejor que estimar en horas en la manera tradicional.
Objetivo
El objetivo es desarrollar un conjunto de métricas mínimamente invasivas que ayudarán a los Scrum Masters a evaluar y aconsejar a los equipos que al mismo tiempo provean valiosos elementos para comprender el rendimiento de equipo y un lenguaje totalmente portable para la comparación de equipos a lo largo de una organización.
[Nota: En este artículo encontrará formulas cuyo tamaño quizá encuentre pequeño. Si es el caso, puede hacerle click derecho sobre alguna fórmula Settings -> Zoom Trigger -> Click esto hará que cada vez que haga click sobre cualquier fórmula, la verá en tamaño grande]
Métricas Propias de Cada Equipo
Éstas dos primeras métricas reflejan Story Points. Debido a que un Story Point es una apreciación de complejidad relativa que los miembros del equipo perciben de los User Stories, es imposible usar estas métricas para comparar el rendimiento de un equipo con otro. Éstas métricas reflejan rendimiento en el contexto del producto que se está desarrollando y el equipo que lo está desarrollando.
Escenario
Con el fin de entender las métricas, crearemos un escenario que engloba los casos contemplados en lo que vamos a medir.
| User Story | Estimación Original | Costo Real | Delta | |
| U.S. #1 | 3 | 2 | 1 | |
| U.S. #2 | 1 | 2 | 1 | |
| U.S. #3 | 5 | 8 | 3 | |
| U.S. #4 | 2 | 5 | 3 | |
| U.S. #5 | 8 | 7 | 1 | |
| U.S. #6 | 13 | 12 | 1 | User Story Tomado del Product Backlog durante el Sprint |
El User Story #6 no formó parte del Compromiso Original hecho por el equipo durante la reunión de Sprint Planning. El equipo terminó el Compromiso antes de finalizar el Sprint y pudo tomar el siguiente User Story de mayor prioridad del Product Backlog, en este caso el User Story #6.
Velocidad
| Yo, como | Product Owner que está tratando de crear una fidedigna hoja de ruta (roadmap) para futuras entregas de software (releases) |
| necesito | una métrica confiable sobre la cual basar mis supuestos acerca de la tasa de progreso del equipo |
| de forma que | yo, con mi liderazgo, pueda hacer análisis de ventajas contra desventajas para hacer compromisos bien informados basado en la realidad de las capacidades de la empresa. |
| Fórmula: |  |
Valor en nuestro escenario: 19.
De esta forma:
donde
Capacidad de Trabajo
| Yo, como | Scrum Master que trata guiar a un equipo hacia la Hyper-Productividad |
| necesito | una forma de medir cuánto trabajo hizo en un Sprint, sea que el trabajo se aceptara en el Sprint Planning o no |
| de forma que | pueda cuantificar la entera capacidad del equipo, hacer preguntas inteligentes sobre distracciones y tomar acción para optimizar la converción de Esfuerzo a Valor |
| Fórmula: |  |
Valor en nuestro escenario: 36.
Métricas Comparables entre Equipos
El cálculo de las siguientes métricas deja en el camino que los equipos estén usando Story Point y ofrecen la capacidad de medir cómo los equipos de su organización están ejecutando de forma comparativa.
Factor de Enfoque
| Yo, como | miembro de las altos puestos de liderazgo que no es un miembro del equipo Scrum |
| necesito | una forma de medir cuánto de la capacidad de cada equipo resulta en un producto entregable, en una forma de comparación entre equipos |
| de forma que | pueda activamente ayudar a equipos sub-optimizados, inteligente ubicar personal y premiar a nuestros equipos por su duro trabajo |
| Fórmula: |  |
Valor en nuestro escenario: 0.52 -> 52%
Ésta fórmula dice cuánto porcentaje del esfuerzo realizado durante el Sprint correspondió a realizar el valor previsto/presupuestado/percibido representado por la Velocidad planeada. Un número interesante para esta métrica está alrededor del 80% significando que el equipo trabajó más de lo planeado pero no por mucho, lo cual es un buen porcentaje de eficiencia para la operación de un sistema no determinístico (cuando digo no determinístico me refiero a la incertidumbre de requerimientos cambiantes y al proceso de creación de software como tal, no al producto de software creado). Un número bajo en esta métrica puede obtenerse por la combinación de dos motivos: 1) Se tomaron User Stories adicionales del Product Backlog antes que terminara el Sprint 2) Se ha dedicado mucho más esfuerzo que el previsto en entregar las User Stories. Un número muy alto (más del 100%) indica una combinación de 1) Se requirió mucho menos trabajo para entregar el mismo valor 2) No se finalizaron User Stories.
Otro cálculo muy útil de factor de enfoque lo propone Henrik Kinberg en su libro "Scrum and XP from the Trenches" [PDF]. Para el Sprint anterior, se calcula el factor de enfoque usando la suma de días hombre de todos los miembros del equipo que realmente se dedicaron a trabajar en el Sprint Backlog:
Una vez calculado nos es útil cuando en la reunión de Sprint Planning queremos estimar la velocidad que podríamos tener en el próximo Sprint dado que 1) algún miembro del equipo estará ausente por algún tiempo por algún motivo, o 2) se une al equipo alguien más.
Fácil:
Trabajo Adoptado
| Yo, como | Scrum Master que trata de guiar a un equipo hacia Compromisos más fidedignos durante cada reunión de Sprint Planning |
| necesito | una métrica que claramente muestre si el equipo tiene una tendencia a sub-comprometerse y consistentemente tiene que tomar trabajo del Product Backlog antes del final del Sprint. |
| de forma que | pueda animar el equipo hacia mayores compromisos durante las reuniones de Sprint Planning sin el riesgo de empujarlos hacia el fracaso. |
| Fórmula: |  |
Valor en nuestro escenario: 0.68 -> 68%
Trabajo Encontrado
| Yo, como | Scrum Master que trata de ayudar a un equipo a hacer Compromisos más fidedignos y confiables durante cada reunión de Sprint Planning |
| necesito | una forma clara de medir la probabilidad de trabajo inesperado basado en el estimado original de una User Story. |
| de forma que | pueda ofrecer consejo al equipo sobre hacer Compromisos alcanzables y proveerles advertencia justa cuando ellos aceptan un User Story que probablemente los sorprenderá |
| Fórmula: |  |
Valor en nuestro escenario: 0.31 -> 31%
Un buen Sprint tiene un valor de a lo más un 20% es lo deseado en esta métrica, eso, junto con entregar más de 80% del Compromiso.
Incremento del Valor Meta
| Yo, como | Product Owner que está tratando de evaluar la eficacia de las direcciones que he escogido para el producto |
| necesito | una forma confiable de medir la contribución de valor incrementado del equipo Sprint tras Sprint |
| de forma que | pueda comparar la tasa del equipo del incremento de la contribución al valor a los cambios en los ingresos que estamos generando y ajustar nuestra dirección si el valor que yo estimé no se concretó |
| Fórmula: |  |
Si la velocidad del próximo Sprint 24, el IVM es de 126%. Si para el tercer Sprint la velocidad es de 37, el IVM es de 194%.
Exactitud de Estimación
| Yo, como | Product Owner que está interesado en crear hojas de ruta confiable, incluyendo fechas de entrega Optimista, Más Probable y Pesimista para iniciativas más grandes |
| necesito | una métrica que pueda rastrear el margen de error de los Estimados Originales del Equipo |
| de forma que | pueda multiplicar sus estimados de buena fe por este factor y crear proyecciones de fechas más realistas. |
| Fórmula: |  |
Donde
y 
De nuevo, un valor de alrededor de un 80% para esta métrica es lo deseable.
En nuestro escenario:
Exactitud de Compromiso
| Yo, como | Product Owner que está interesado en la exactitud de mis hojas de ruta |
| necesito | una métrica que me informe del margen de error cuando el equipo se compromete a cierta cantidad de trabajo |
| de forma que | yo pueda utilizar este margen de error para predecir fechas confiables y saber cuándo es seguro cabildear por un mayor Compromiso en cada reunión de Sprint Planning. |
| Fórmula: |  |
En nuestro escenario:
Y de nuevo, una valor alrededor del 80% es el ideal.
