Cómo estimar y clasificar errores usando métodos Scrum

Primero, si va a realizar un seguimiento de cuánto tiempo o esfuerzo se está utilizando en los errores, debe insertarlos en su proceso de seguimiento actual como un “tipo” de historia de usuario que no está necesariamente orientado al usuario.

En segundo lugar, una buena manera de controlar y clasificar sus errores es simplemente dejar de lado un porcentaje específico de esfuerzo en cada sprint que se dedica a resolver los errores que ha priorizado y estimado, esencialmente creando una acumulación “bifurcada”. Los errores más importantes se ubican en esa capacidad preestablecida, hasta que se llena, luego las historias de usuarios de negocios ocupan el resto del sprint.

Para lidiar específicamente con el mundo posterior al lanzamiento, solo deje de lado un sprint después del lanzamiento que esté totalmente (o principalmente) dedicado a resolver problemas relacionados con el lanzamiento (y asegúrese de que esté buscando la causa raíz para minimizar los problemas futuros). Si generalmente haces un 20% de errores, un 80% de historias, dale la vuelta por un sprint y conviértelo en un 80% de errores, un 20% de errores.

No debe sentirse limitado por ningún proceso verdaderamente ágil; la razón por la que es “ágil” es que debe estar dispuesto y ser capaz de hacer lo que necesita para hacer su trabajo al final del día. La adherencia ciega al proceso dogmático es antitética a los principios “ágiles”.

Scrum no es una ciencia exacta y la “promesa” es una terminología en cascada. Para de hacer eso.

Todo en Scrum es una suposición, y las suposiciones mejoran con la iteración. El viejo adagio de que una historia tiene 70% de claridad entrando y 100% de claridad saliendo, es verdad. Si Scum no cumple una estimación, no es el fin del mundo, porque puedes ajustarte cada dos semanas. Está diseñado para responder a ese tipo de cambios. Tratar de imponer promesas rígidas en el scrum rompe el flujo. Deje que el equipo desarrolle un ritmo sostenible porque los equipos son inherentemente eficientes si se dirigen (no están microgestionados) bien. Si no puede confiar en su equipo, ese es un problema mucho mayor. Si el scrum master no mantiene a las partes interesadas fuera del sprint, eso también es una señal de alerta.

Entonces, a su pregunta, si un equipo tiene una velocidad establecida de 39 puntos por sprint (un número completamente relativo, interno para el equipo y no generalizable a otros), entonces podría decir que los errores P0 y P1 siempre están en la parte superior de la cartera de pedidos. , pero por lo demás, el equipo debería dedicar aproximadamente 12 puntos por sprint a errores versus nuevas historias. El propietario del producto debe mantener las historias frescas y organizadas y el equipo de desarrollo hará el resto.

Si se encuentran errores después de que se lanzan las características, estos errores deben tratarse como cualquier otro trabajo que complete en un Sprum Sprint, incluido el hecho de estar representado en el cuadro de quemado.

Sprint Backlog ≠ Historias de usuarios

Scrum no exige que todo el trabajo completado en un Sprint deba expresarse como historias de usuario. De hecho, la Guía Scrum no menciona historias de usuarios en absoluto. El formato de la historia del usuario surgió como una ‘mejor práctica’ para ayudar a los equipos a documentar los requisitos.

La deuda técnica es un mal necesario

Desafortunadamente, la deuda técnica es un mal necesario y, a veces, debe introducirse en su producto porque la calidad debe verse comprometida en ese momento específico (por ejemplo, debe cumplirse el plazo, no está seguro de la nueva tecnología y la investigación llevará demasiado tiempo, etc.) .

Pero … si a sabiendas incurres en la deuda, debes pagarla. Entonces, al crear su tabla de quemado, no puede simplemente cancelar la deuda.

Clasificación y estimación de errores

Al igual que cualquier otra tarea en su Sprint, el Propietario de un producto prioriza su acumulación de errores con la misma mentalidad que las características, y permite que el Equipo de desarrollo las calcule durante la Planificación de Sprint.

Hola 🙂

Elegiste un tema muy interesante.

Lidiar con la estimación de errores es lo que muchos equipos de TI tienen en común. Los procesos construidos a su alrededor suelen ser lentos y poco productivos. No necesariamente tiene que ser así. Puede disminuir los costos y la complejidad del proyecto, así como aumentar la eficiencia. Recientemente hicimos una publicación de blog sobre este tema, creo que lo encontrará interesante. Fue escrito por nuestro Scrum Master en Pragmatic Coders:

Estimación de errores: por qué no vale la pena el esfuerzo

He ido una y otra vez sobre el valor de estimar errores. En estos días, tiendo a alentar a mis equipos a estimar errores. Sin embargo, agrupo los errores en 2 grupos:

1. Errores WIP (trabajo en proceso) generados a partir de su trabajo en nuevas historias de usuarios
2. Defectos escapados encontrados fuera del equipo (clientes, etc.) después del lanzamiento.

Los errores de WIP caen en su cubo de deuda tecnológica ya pagada. Idealmente, los equipos no consideran una historia de usuario realizada hasta que se corrijan todos los errores de WIP.

Los defectos escapados deben quemarse en un presupuesto fijo. El presupuesto podría no ser puntos, podría ser algo así como “quitamos los errores X principales del retraso acumulado del defecto cada sprint”. Ajuste “X” para que sea lo suficientemente grande como para mantener el trabajo atrasado bajo control, no es necesario estimar

Sin embargo, una ventaja de estimar errores, especialmente los defectos escapados, es que pone un costo muy real en la mala calidad de la versión. El equipo puede mirar hacia atrás y ver qué fracción de su tiempo pasó reparando errores que no se detectaron en sus procesos de control de calidad y hacer cambios para evitar que dichos errores escapen en el futuro. Esta estimación podría ser una evaluación retrospectiva diferida hasta después de que se solucione el error.

En cualquier caso, al planificar la versión futura, el equipo debe ser consciente de que solo la velocidad de la historia del usuario es pertinente para la planificación. Los puntos de historia gastados en errores no representan un avance en la hoja de ruta / backlog de lanzamiento.