Scrum: ¿Qué hacer con Story Points del Carry Over?

 

¿Qué hacer con Story Points del Carry Over?

Este post lo escribo debido a que una capacitación que dicté actualmente me preguntaron esto: "¿que hacer con los story points del carry-over?". Cuando un equipo Scrum termina un Sprint y le queda una Historia de Usuario de Carry Over que estaba estimada en X story points y se quemaron solo N story points, quedando un remanente de X-N story points ¿Qué se recomienda hacer? 

Antes de comentar las estrategias recomendadas vamos a revisar algunas afirmaciones teóricas. Teóricamente se puede considerar lo siguiente:

1. El Velocity es una métrica utilizada en el marco de trabajo Scrum para medir la cantidad de trabajo que un equipo puede ‘completar’ durante un Sprint. Se calcula sumando el número total de story points ‘completados’ por el equipo en un Sprint determinado. El trabajo que no cumple con los criterios de aceptación del Product Owner o del cliente no se puede considerar como completo. Según Mike Cohn: "Velocity es la cantidad de trabajo completado por un equipo de desarrollo durante un sprint. Se mide en story points para las historias de usuario completadas. Velocity se utiliza para la planificación del sprint futuro, ya que proporciona una idea de la capacidad del equipo para completar trabajo en un sprint determinado". El velocity refleja trabajo completado, que cumple el Definition of Done, porque es un acercamiento a: “¿Cuánto Valor entregamos por Sprint?” (Jeff Sutherland); y valor es el trabajo completado (esfuerzo aceptado) no el quemado (esfuerzo realizado).

2. La estimación: es importante, teniendo en cuenta que el objetivo es proporcionar una guía para el trabajo a realizar y ser una medida para poder mejorar y no es una medida exacta del esfuerzo requerido. La estimación debe ser lo suficientemente precisa para ayudar al equipo a planificar el trabajo para el Sprint, pero también lo suficientemente flexible para permitir ajustes si es necesario.

3. El Velocity incluye historias terminadas para incluir una historia en el cálculo de Velocity, debe haber cumplido con todos los criterios del Definition of Done y haber sido aceptada por el Product Owner o el cliente.

4. El Velocity no incluye historias no terminadas. Las historias que no fueron aceptadas por no cumplir con los criterios del Definition of Done no deben incluirse en el cálculo de Velocity, incluso si tienen story points realizados.

5. El Carry Over: es una User Story Comprometida y No Aceptada por el Product Owner por no cumplir el Definition of Done.

6. El Carry Over NO es un conjunto de Puntos de una User Story no terminados en el Sprint; los puntos de historia son los que están asociados a una historia Carry Over.

7. Los Story points quemados de la historia no completada no se consideran trabajo completado y no se reflejarán en el incremento del producto entregado al final del Sprint debido a que la historia no cumple el DOD entonces sus Story Points quemados tampoco se consideran terminado. Deben ser considerados como trabajo incompleto en el Sprint actual y no deben incluirse en el cálculo del Velocity.

8. Los Story points quemados de la historia no completada son parte del Capacity del Sprint pero no del Velocity.

9. Historias NO Aceptadas vuelven al Backlog para poder ser evaluadas en una próxima planning. Según Mike Cohn: “Cuando un elemento de la cartera de productos no se termina al final de un sprint ágil, técnicamente debería volver a colocarse en la cartera de productos. El trabajo nunca se mueve automáticamente de un sprint al siguiente”.

10. En la próxima reunión de Planning del equipo, los story points que se quemaron en la historia no aceptada se deben tener en cuenta como un trabajo incompleto en el Sprint anterior y no se deben contar en el Velocity del Sprint actual. Solo se cuenta el remanente o el re-estimado.

11. Los story points remanentes de la historia no aceptada se deben estimar nuevamente en el siguiente Sprint. Sin embargo, si el equipo siente que ya comprende mejor la historia y tiene más información para estimarla con mayor precisión, pueden ajustar la estimación original de la historia y estimar lo que les queda por hacer.

12. En la próxima reunión de Planning del equipo, los story points remanentes de la Historia de Usuario que quedaron sin quemar en el Sprint anterior deben ser incluidos en la estimación del trabajo a realizar para el siguiente Sprint planificado.

13. Hay una distinción entre "velocidad" (puntos de historia de historias completadas según la estimación original) y "capacidad de trabajo" (puntos de historia quemadas según la estimación revisada).

Discho lo anterior, ahora sí veamos las estrategias principales.

Estrategia 1: Registrar puntos quemados y arrastrar remanentes

Siguiendo la teoría, la primera estrategia es registrar los puntos quemados versus los completados. En el siguiente ejemplo podemos ver que en el Sprint 2 se comprometió una historia de estimada en 3 story points, que no fue aceptada. Por eso no se contaron los puntos quemados como velocity, pero como se quemó un story points este sí se contó como capacity. Para el Sprint 3 se incluye la misma historia, pero se comprometen los story points que faltaron quemar.

De este modo se puede ver que los story points quemados de una historia que es carry over se pierden para el velocity, aunque sí se contabilizan para el capacity.

Esta estrategia requiere disciplina del Scrum Master registrando los valores de puntos comprometidos, quemados y completados y hacer los cálculos apropiados. También requiere que el equipo estime cuántos puntos quemaron del total estimado, algo bastante subjetivo y que requiere disciplina.

Estrategia 2: sin puntos quemados y acarrear remanentes

Siguiendo la teoría, tenemos una segunda estrategia: no registrar puntos quemados. La estrategia 2 es que los puntos quemados del total estimado no se registran, en consecuencia no haremos distinción entre velocity y capacity. Solo usaremos el velocity y si una historia es carry over no se cuentan los puntos quemados, se cuenta cero (y se mueve al Backlog para próximo Sprint). Y luego en próximo Sprint se re-estima sólo el trabajo remanente de la historia (se desestiman los puntos del trabajo ya realizado).

Aquí se puede decir que los puntos quemados parecen perderse, porque no se tienen en cuenta para el velocity. Este velocity es un velocity más efectivo que refleja los puntos que el equipo realmente termina independientemente de los que quema. Igual cumple la teoría, solo que la gestión es más simple. 

Bajo ambas estrategias, podríamos querer guardar la “estimación original” (o estimación total) para no perder la información de cuánto realmente pesó la historia, para estimaciones futuras. Ya que las historias carry-over pueden ser re-estimadas en las re-planificaciones.

Una típica pregunta es que si pierdo storypoints y afecto al velocity real. La verdad que importa más la velocidad promedio, y lo que no se cuenta en un sprint se cuenta en otro, y se compensan para la velocidad promedio. La velocidad promedio se suele calcular en 3 Sprint o en 6 sprints e indica, más aproximadamente, la capacidad de entregar valor del equipo en un sprint.

Estrategia 3: sin puntos quemados y acarrear puntos totales

Tenemos una tercera estrategia: no registrar puntos quemados y acarrear el total de puntos. La estrategia 3 es que los puntos quemados del total estimado no se registran, en consecuencia no haremos distinción entre velocity y capacity. Solo usaremos el velocity; y si una historia es carry-over no se cuentan los puntos quemados, se cuenta cero (y se mueve al Backlog para próximo Sprint). Y luego, en el próximo Sprint se re-estima toda la historia (incluyendo el trabajo hecho) y se considera el puntaje total en el Sprint nuevo. Esto no sigue la teoría, porque no tendremos un velocity real, los puntos entregados, si la historia acarreada de carry over se termina, estarán en este último Sprint y eso no refleja ni el capacity ni el velocity real del Sprint. Aunque si solo prestamos atención, al momento de estimar, al ‘velocity promedio’, tendremos una aproximación al capacity promedio. Es decir que el average velocity es una aproximación de la capacity que podría tener el equipo. Esta estrategia, aunque no respeta la teoría, también es simple de implementar.

Pueden haber otras estrategias, aunque estas tres son las más usadas. Muchas veces recomiendo la estrategia 2, por simplicidad y respetar la teoría; aunque hay personas que sienten que pierden puntos. Y la estrategia 2 es incómoda para un equipo que está muy centrado en el output.

Carry Over en Jira

En Jira, la estrategía por defecto y la más simple es la estrategia 2 y 3: no registrar puntos quemados.

• Generalmente en Jira, en las configuraciones por defecto, se estima en Story Points y “Los issues (Historias de usuario) consumirán su valor de Story Points al finalizar” (al pasar a Done).

• Si una historia de carry over se compromete en el próximo sprint sin modificar los story points y se termina el sprint con la historia aceptada, Jira contabilizará el total de la estimación original.

• Jira, por defecto, no diferencia entre el trabajo realizado en diferentes sprints para una misma historia de usuario. Si la historia de carry over se completa en el siguiente sprint, Jira considerará la estimación total de la historia de usuario para calcular el Velocity del sprint en el Sprint que se ha completado la historia.

• Las Historias Carry Over no suman puntos para el velocity, solo sumarán en el Sprint que se termine (que pase a Done).

• El ‘Sprint Report’ o ‘Informe de Sprint’ le mostrará las historias no completadas en cada Sprint, estas son el Carry Over.

• El Burndown Chart de Story Points decrecerá solo a medida en que las historias vayan completando (Done).

• Depende si usamos la estrategia 2 o la 3, si decidimos descontar puntos quemados y acarrear remanente o acarrear todos los puntos.

• Las historias que fueron Carry Over quedan con su campo Sprint con los Sprint en que estuvieron.

Referencias:

• MEASURING SCRUM: ESSENTIAL METRICS FOR HYPER PRODUCTIVE TEAMS" de los autores Jeff Sutherland y Scott Downey de Scrum Inc.

• Mike Cohn define la Velocity de Scrum en su libro "Agile Estimating and Planning", publicado en 2005.

• "Scrum: A Pocket Guide" de Gunther Verheyen: Este libro es una introducción clara y concisa a Scrum y sus principios. Verheyen explica cómo se utiliza la Velocity en Scrum para medir la capacidad del equipo y cómo el Carry Over puede afectar la planificación del Sprint.