Tenemos nuevos equipos trabajando en scrum y estiman todos los puntos de varias historias. Pero, al principio, no tienen ninguna referencia de la cantidad de puntos que se pueden entregar en un sprint de dos semanas.
Vemos al final de los sprints que no se están completando todos los puntos. Cerca del final, el equipo es abrumador y la calidad se sacrifica solo por la entrega a tiempo.
Quiero saber si este tipo de KPI tiene sentido en el entorno scrum, y si no, ¿cómo podemos asegurar que el equipo sea tan productivo como lo es normalmente?
Scrum no se trata intrínsecamente de hacer más trabajo más rápido, aunque los equipos de alto rendimiento a menudo lo hacen. Como la mayoría de los marcos ágiles, Scrum se trata de hacer lo suficiente del trabajo correcto .
Medir al equipo contra una velocidad objetivo es un antipatrón de Scrum, al igual que medir la productividad a partir de la cantidad de elementos pendientes o puntos de la historia completados. En su lugar, debe medir la eficacia del equipo Scrum (¡incluida la eficacia del propietario del producto!) para cumplir el objetivo del Sprint en cada iteración.
El objetivo de un Sprint nunca es hacer mucho trabajo, completar N historias, igualar las velocidades históricas o proyectadas, o lograr el 100 % de utilización de los recursos. Si está manejando este tipo de métricas, está violando los principios básicos de Agile y Scrum.
En Scrum, el Sprint es un cuadro de tiempo efímero que se llena con elementos de la cartera de productos que:
Este enfoque en una coherencia central no es discrecional. Es un elemento fundamental de Scrum formal. La sección Planificación de Sprint de la Guía Scrum dice:
Objetivo de carrera
El Sprint Goal es un objetivo establecido para el Sprint que se puede cumplir mediante la implementación de Product Backlog. Brinda orientación al Equipo de desarrollo sobre por qué está construyendo el Incremento. Se crea durante la reunión de Planificación de Sprint. El Sprint Goal le da al Equipo de Desarrollo cierta flexibilidad con respecto a la funcionalidad implementada dentro del Sprint. Los elementos del Product Backlog seleccionados ofrecen una función coherente, que puede ser el Sprint Goal. El Sprint Goal puede ser cualquier otra coherencia que haga que el Equipo de Desarrollo trabaje en conjunto en lugar de en iniciativas separadas.
A medida que el Equipo de Desarrollo trabaja, tiene en mente el Sprint Goal. Para satisfacer el Sprint Goal, implementa funcionalidad y tecnología. Si el trabajo resulta ser diferente de lo que esperaba el equipo de desarrollo, colaboran con el propietario del producto para negociar el alcance del Sprint Backlog dentro del Sprint.
La velocidad es una métrica de uso común en marcos ágiles, pero no es formalmente parte de Scrum. Además, el uso correcto de la velocidad nunca es un objetivo de gestión o una medida de productividad. Cuando se usa correctamente, la velocidad debe ser:
En Scrum, el trabajo planificado nunca debe exceder la duración de una sola iteración. Terminar temprano es excelente, mientras que una holgura insuficiente generalmente reducirá el flujo y el rendimiento.
Si bien la velocidad puede ser útil en la estimación inicial de la cartera de pedidos , la planificación ágil de lanzamientos , la capacidad de pronóstico para el Sprint actual o la identificación de problemas de procesos ocultos a través del análisis de líneas de tendencia , definitivamente no es una medida precisa de productividad a nivel individual o incluso de equipo. Es un valor de planificación y (en menor medida) un control de detección para el proyecto.
Velocity a menudo se usa incorrectamente como un objetivo de administración y una forma de "responsabilizar a los desarrolladores". Si estás haciendo esto, ¡estás haciendo lo ágil mal!
La velocidad es una métrica sustituta de la capacidad , y las perturbaciones en el flujo suelen atribuirse a:
Suponiendo que su equipo haya alcanzado una velocidad estable , si la velocidad cae repentinamente, entonces debería trabajar con el equipo (y especialmente con el propietario del producto) para identificar los problemas subyacentes del proceso. Una vez identificados, los problemas se pueden abordar de varias maneras, incluida la negociación del alcance, la terminación anticipada del Sprint y los eventos de inspección y adaptación, como las Retrospectivas del Sprint.
Vemos al final de los sprints que no se están completando todos los puntos.
Sí, esto no debería pasar. Haga todo lo posible para que este escenario sea muy poco probable. Por ejemplo, incorpore al Sprint lo que parecería ser una cantidad ridículamente poco ambiciosa de elementos de la Lista de Producto (PBI), con el objetivo de brindarle al equipo la experiencia de completar un Sprint temprano: ¿qué eligen hacer con esta 'holgura'? ¿hora?. Un experimento realmente interesante es incluir solo un PBI en el Sprint, con el objetivo de brindarle al equipo de desarrollo la oportunidad de experimentar con la autoorganización: ¿se agruparán para completar el trabajo?
Cerca del final, el equipo es abrumador y la calidad se sacrifica solo por la entrega a tiempo.
Sí, esto tampoco debería pasar. Además de la sugerencia anterior, haga que los equipos revisen su Definición de Listo (probablemente compartan una). ¿Es lo suficientemente riguroso? ¿Se está aplicando? ¿Alguno de ellos puede ser automatizado? La calidad no es negociable y se pueden lograr cero errores.
erik
josebel luna