August 27, 2020

Usar la velocidad en puntos de historia no es obligatoria en Scrum

La velocidad no es obligatoria en Scrum

Scrum se ha convertido en el marco ágil de trabajo más usado en el desarrollo de software en el mundo. Uno de los beneficios de Scrum es la entrega de incrementos de producto en periodos de tiempo cortos. El trabajo se basa en la colaboración y trabajo en equipo. Algunos aspectos como el descubrimiento, el empirismo y la inspección continua son claves para lograr un proceso de mejora continua y de innovación en el producto a construir.  Scrum está basado en un proceso de empírico y sirve para construir productos complejos de forma sostenida. Empírico es aprender de la experiencia validada en el mercado.

El Planning Poker no es una práctica obligatoria en Scrum, aunque puede ser útil como una forma de facilitación para fomentar la conversación y generación de ideas. Los Story Points o puntos de historia están basados en tamaño, esfuerzo y complejidad, no representan horas, minutos, días o cualquier otra métrica que indique duración. Los puntos de historia son influenciados por el riesgo, la incertidumbre y es diferente para cada equipo. Representan el esfuerzo para terminar un Product Backlog Item según los criterios de terminado. El ejercicio del planning poker es fundamentalmente una dinámica de colaboración donde el equipo de desarrollo aprende mediante la discusión acerca de cómo desarrollar los Product Backlog Items (PBIs) y los supuestos que definen para ello como los criterios de aceptación y preguntan al Product Owner sobre sus dudas. La estimación en complejidad es una referencia para que el equipo pueda tomar decisiones acerca de que ítems podrían requerir más refinamiento, que ítems tienen más riesgo, que ítems pueden tener dependencias y que alternativas se pueden plantear, este ejercicio puede afectar el orden de los ítems en el Product Backlog y puede influenciar la forma en que el equipo define su Sprint Backlog.

Scrum no prescribe una forma de estimación, Scrum se basa en la auto organización para todo el trabajo que el equipo tiene que lograr para enfocarse en el objetivo del Sprint.

La velocidad se obtiene de la suma de los puntos de historia de los PBIs terminados en un Sprint. La velocidad por sí sola no necesariamente permite predecir la capacidad futura de un equipo de desarrollo en los siguientes Sprints. La velocidad no mide el desempeño pasado de un equipo ya que no necesariamente refleja la mejora en entrega de valor de negocio ni mejora continua. Cuando el trabajo es complejo no se debería esperar que la velocidad sea similar en el tiempo y que ello sirva como predicción del futuro. Cuando usamos Scrum, siempre debemos planificar para lo inesperado. Aunque puede ser usado para proyectar, no debemos buscar que el compromiso sea hacia la velocidad en lugar de la entrega de valor. El uso de la velocidad no es obligatorio en Scrum. Buscar equivalencia de los puntos de historia hacia unidades de tiempo fijas puede atentar contra la autoorganización, mejora continua, creatividad y trabajo en equipo.

La velocidad tampoco es una medida de productividad del equipo de desarrollo. Medir las mejoras del trabajo en equipo en función de la velocidad puede llevar a distorsiones en el uso de Scrum y el empirismo. La velocidad no debería ser normalizada entre varios equipos de Scrum como una métrica para comparar el rendimiento de diversos equipos de desarrollo. Es peligroso comparar las velocidades debido a que puede inducir al equipo a enfocarse en la velocidad y no en mejorar la entrega de valor de negocio.

Buscar que la velocidad sea constante en cada Sprint o que crezca no es el objetivo. Buscar una velocidad deseada no es algo adecuado ya que esa velocidad no existe en un entorno empírico. El compromiso del equipo de desarrollo no es con una velocidad en puntos de historia en un Sprint sino con la entrega de valor reflejado en el Sprint Goal. El objetivo es mejorar la entrega de valor.

Pedirle a un equipo que mejore su productividad mejorando su velocidad puede provocar que se logré la velocidad esperada artificialmente, esto es influenciando al equipo para que cambie su enfoque del objetivo del Sprint y no use los valores de Scrum.

Existen alternativas para tomar métricas de referencia como las métricas de Kanban.

Les comparto el enlace donde pueden adquirir mi libro Notas de Scrum Profesional: https://www.amazon.com/dp/B082S26DLH

Pueden ver la siguiente programación de los cursos oficiales que brindo en:

https://www.discoveryfast.com/certificaciones

Me pueden contactar en jfrancia@discoveryfast.com