Scrum: Entendiendo los Lead Times en el Sprint de Scrum

Queridos Scrum Masters, en la búsqueda de la mejora continua y la optimización de los procesos de desarrollo de software, es fundamental comprender los diferentes Lead Times y su impacto en la eficiencia de entrega. En este artículo, exploraremos los conceptos clave de Development Lead Time, Delivery Lead Time y QA Lead Time, y cómo pueden contribuir a acelerar el ciclo de desarrollo y despliegue en producción. ¡Vamos a sumergirnos!

El Lead Time y sus puntos límites

Primero revisemos de qué hablamos con Lead Time. Una definición Lean de "Lead Time es la cantidad total de tiempo que pasa desde que se recibe una solicitud de un cliente hasta que se entrega el producto o servicio solicitado. Incluye el tiempo de espera, el tiempo de procesamiento y el tiempo de transporte o entrega". Podemos ver esa definición como Lead Time Total de todo el proceso de desarrollo de features. Esa definición en Scrum no nos es tan útil, porque desde que un ítem entra al bácklog, se refina y se planifica puede pasar mucho tiempo y suele ser muy irregular. Otra definición que podemos usar, desde el punto de vista de un equipo Scrum, es que el Lead Time es el tiempo que transcurre desde que se compromete un trabajo para hacerse (no cuando comienza el trabajo) hasta que se completa el trabajo. Una vez que se compromete a entregar el trabajo (que en un equipo Scrum se da en la planning), el reloj de su tiempo de entrega comienza a correr.

Aquí hay una gran diferencia entre el momento en que el cliente da una solicitud (o se genera un nuevo ítem de backlog) y el momento en que el equipo se compromete a entregarla (Sprint Backlog en planning). No són la misma cosa. No debe comprometerse a entregar una solicitud en el momento en que llega. Si no es crítico, el elemento de trabajo debe pasar por su proceso Upstream (generación, priorización y refinamiento) antes de realizar su compromiso final (Sprint Backlog). Piense en su proceso Upstream (desde el punto de vista de equipo) como un embudo: no todos los elementos de trabajo pasarán, habrá elementos en los que se comprometa a trabajar ahora, otros que deje para más adelante y otro tipo que descartará por completo. 

No comprometa entregar un elemento de trabajo hasta que haya seleccionado ese elemento de trabajo para su próxima iteración. Y deje de corre el tiempo del Lead Time en el momento en que su trabajo llega a la columna "Terminado/Done", el 'delivery-point'. O sea que depende, en gran medida, de su Definition-Of-Done que permite pasar un ítem por el delivery-point.

En un equipo Scrum, los Lead Times que más nos importa son los que se encuentran después del punto de compromiso (commitment-point) hasta el punto de entrega (delivery-point).

Los tres Lead-Times más importantes en desarrollo

Para empezar, el Development Lead Time se refiere al tiempo que transcurre desde que se compromete e inicia el trabajo en una historia o requerimiento específico hasta que se completa el desarrollo del código necesario para implementar ese cambio. Incluye todas las etapas de desarrollo, como el diseño, la codificación, las pruebas unitarias y las pruebas de integración en el entorno de desarrollo. El "Development Lead Time" se enfoca en el proceso interno del equipo de desarrollo y mide su eficiencia en la implementación de cambios. En general, se considera que el Development Lead Time incluye todas las etapas desde el inicio del trabajo en la tarea hasta que el código está listo para ser entregado a las pruebas.

Por otro lado, Delivery Lead Time básico abarca desde su punto de compromiso hasta su punto de entrega. A nivel de ingeniería de software abarca, no solo el desarrollo, sino también las etapas posteriores, como las pruebas de integración en ambientes de QA y staging, la aprobación del producto, el despliegue en producción y la verificación en producción. Idealmente mide el tiempo total que lleva entregar un cambio en producción y ponerlo a disposición de los usuarios finales. 

La definición de "product delivery lead time" que se da en el libro "Accelerate" incluye el tiempo que lleva desde que se realiza la codificación hasta que se implementa en producción. En el contexto de medición del delivery lead time, se considera el momento en que se realiza el commit como el punto de partida para medir el tiempo que tarda el cambio en llegar a producción. A este "product delivery lead time" también lo podemos llamar "product delivery lead time" o "DevOps Delivery Lead Time".

Finalmente, el QA Lead Time: o "Quality Assurance Lead Time", se refiere al tiempo que transcurre desde que un cambio o desarrollo de software se considera listo para ser sometido a pruebas de calidad hasta que se completan dichas pruebas.

Los Lead-Times en el Sprint

Integrar eficientemente el Development Lead Time y el QA Lead Time dentro de un Sprint de Scrum es fundamental para lograr un proceso de desarrollo de software efectivo y generar un incremento de producto potencialmente entregable. Aunque el "santo grial" de Scrum es integrar los tres Lead Times, incluyendo el Delivery Lead Time, y que el Delivery Lead Time sea el Product Delivery Time, porque solo así es como se genera incremento de producto, entregado al usuario, dentro de un Sprint.

Aquí te presento algunas razones por las que esta integración es necesaria:

1. Entregas frecuentes y valor temprano: Al optimizar el tiempo de desarrollo, pruebas y entrega, el equipo puede realizar entregas frecuentes de funcionalidades al final de cada Sprint. Esto permite que el cliente o usuario final obtenga valor temprano y realimentación oportuna sobre el producto. Además, las entregas frecuentes también ayudan a identificar y corregir posibles problemas más rápidamente.
2. Adaptación y flexibilidad: Al integrar los tiempos de desarrollo y pruebas dentro del Sprint, el equipo tiene la oportunidad de evaluar continuamente el progreso y realizar ajustes si es necesario. Si se descubren problemas o desafíos durante las pruebas, el equipo tiene la posibilidad de adaptarse y tomar medidas correctivas para garantizar la calidad y la entrega exitosa.
3. Reducción de desperdicio: Integrar eficientemente el Development Lead Time y el QA Lead Time ayuda a eliminar actividades innecesarias y a reducir el desperdicio en el proceso de desarrollo. Al tener una colaboración estrecha entre los roles de desarrollo y QA, o desarrolladores fullstack y "t-shaped person" que desarrollan y hacen QA se evitan retrasos y se optimiza la utilización de recursos, lo que a su vez mejora la eficiencia general del equipo.
4. Transparencia y visibilidad: Al generar un incremento de producto potencialmente entregable al final de cada Sprint, o en el mejor de los casos un incremento entregado, se brinda transparencia y visibilidad tanto al equipo como a los stakeholders. Esto les permite evaluar y verificar el progreso realizado y proporciona una base sólida para la toma de decisiones informadas. La transparencia también promueve una comunicación abierta y una mayor confianza entre todos los involucrados para inspección y adaptación constante.
5. Mejora continua: Al medir y monitorear estos Lead Times, el equipo puede identificar oportunidades de mejora y establecer metas realistas para optimizar el proceso de desarrollo. Esto fomenta la mentalidad de mejora continua y permite al equipo implementar cambios y prácticas que impulsen la eficiencia y la calidad del producto.

En resumen, integrar eficientemente el Development Lead Time, el QA Lead Time y el Delivery Lead Time dentro de un Sprint de Scrum y generar un producto potencialmente entregable es esencial para lograr entregas frecuentes, adaptabilidad, reducción de desperdicio, transparencia y mejora continua. Esto asegura que el equipo de desarrollo esté enfocado en entregar valor de manera constante y satisfacer las necesidades del cliente o usuario final de manera efectiva.

Antipatrones

Siempre que queremos hacer algo bien podemos hacerlo mal. Los antipatrones son soluciones o prácticas contraproducentes que pueden generar problemas e impedir buenas prácticas, el buen desarrollo de software y la adopción del marco de trabajo. Identificar y evitar estos antipatrones es fundamental para lograr un desarrollo eficiente y de calidad.

Hay algunos antipatrones en Scrum que impiden integrar eficientemente el Development Lead Time, el QA Lead Time y el Delivery Lead Time dentro de un Sprint. Por ejemplo los siguientes:

• Scrumfall o Scrummerfall: Este antipatrón se refiere a la combinación de Scrum y Waterfall en un enfoque híbrido o en un Scrum cosmético. En este caso, el equipo puede realizar los eventos de Scrum, pero aún sigue una secuencia de desarrollo en cascada: desarrollan en un Sprint, hacen pruebas y certifican en el sprint siguiente y despliegan en otro. De esta manera es imposible terminar una historia de usuario que cumpla criterios INVEST dentro de un Sprint y cumplir un Definition of Done de calidad. Esto puede afectar la integración eficiente de los tiempos de desarrollo, pruebas y entrega en el Sprint.
• The Offshore Blender: Este antipatrón se refiere a la integración de un equipo offshore u outsourcing sin una comunicación ni colaboración efectiva entre los miembros del equipo. También cuando existe una falta de alineación entre la empresa cliente (que quiere adoptar Agile/Scrum) y el proveedor de Outsourcing (que no es Agile/Scrum) en términos de metodología de desarrollo.  Ocurre cuando, por ejemplo, un equipo externo hace el desarrollo, y el QA lo hace otro equipo interno de la organización. Esto puede afectar la integración eficiente de los tiempos de desarrollo, pruebas y entrega en el Sprint.
• Silos Work: Si hay un conocimiento limitado o exclusivo dentro de ciertos roles o equipos independientes, que trabajan en silos, puede haber una dependencia excesiva en individuos específicos para realizar tareas críticas. La existencia de silos, además, por lo general tiene aparejada burocracia. Esto puede provocar cuellos de botella y retrasos en el proceso de desarrollo, ya que los miembros del equipo no pueden trabajar de manera colaborativa, fluida y autónoma. Esto ocurre cuando un equipo hace el desarrollo, otro el QA y/o un tercero el despliegue a producción (o aprobaciones burocráticas).
• Little automation: la falta de automatización de pruebas puede llevar mucho tiempo realizar pruebas exhaustivas de manera manual. Esto puede aumentar el QA Lead Time y retrasar la entrega de software de calidad. La falta de automatización también puede aumentar el riesgo de errores y problemas de calidad.
• Poor Definition-Of-Done: una definición de "Done" pobre o/y su incumplimiento es un antipatrón común. Si el equipo no tiene una definición clara y consensuada de "Done" para cada elemento de trabajo, puede haber ambigüedad sobre cuándo se considera que una historia está completada. Tener un DOD pobre, por ejemplo uno que se limita a pasar solo historias que tienen los criterios de aceptación cumplidos pero deja fuera los requisitos de QA, peploy y delivery, es una manera de auto-mentirse o puentear la excelencia técnica y evadir la finalidad del Timebox y el DOD. Esto puede dificultar la integración y la entrega oportuna, ya que pueden surgir discrepancias sobre el nivel de calidad y finalización del trabajo.

Pueden haber muchos otros antipatrones que puedes investigar. 

Es importante que los Scrum Master y los equipos de Scrum reconozcan estos antipatrones (y otros) y trabajen en conjunto para superarlos. Al fomentar una cultura de colaboración, transparencia, automatización y mejora continua, se pueden eliminar estos obstáculos y lograr una integración eficiente de los tiempos de desarrollo, pruebas y entrega dentro de los Sprints de Scrum.

Referencias:

1. Nicole Forsgren, Jez Humble y Gene Kim: En el libro "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations".
2. Jez Humble y David Farley: En el libro "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation".
3. "The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations" por Gene Kim, Jez Humble, Patrick Debois y John Willis. 
4. "Testing in DevOps: A Guide for Software Testers and Anyone Involved in Software Delivery" por Katrina Clokie. 
5. Sonya Siderova, Lead time vs cycle time in kanban.

 

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.

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.