Autora: Nancy Lopez TM – Professional Scrum Master at Globant

Los Scrum Masters nos encontramos con el desafío de enseñar a nuestros equipos a reflejar en forma adecuada todo el esfuerzo que hacemos para satisfacer las necesidades de calidad de nuestros Clientes. Uno de estos desafíos tiene que ver con las tareas de bugfixing (dentro de un Sprint o de Sprints finalizados).
 
La primer regla es siempre resolver los bugs que impidan el cumplimiento del Criterio de Aceptación de la User Story (US) o aquellos relacionados con un Requerimiento No Funcional.
 
¿Pero qué hacemos con el resto?  El secreto es saber REPLANIFICAR.
 
Como dueños del Sprint el Team y el PO hay que utilizar la Scrum meeting para detectar cambios de prioridades y ajustar el camino a seguir.  Nos tenemos que preguntar si el largo listado de Bugs es prioritario o no, y de serlo,  si es más prioritario que las US ya comprometidas para el Sprint.
En base a las prioridades definidas se procede a quitar del Sprint las US que NO se desarrollaran y agregar los Bugs a resolver.
¿Cómo evitar que siga pasando? 
Lo primero que tenemos que hacer es analizar lo sucedido:
1-  Si nos equivocamos al estimar las tareas de testing relacionadas con la US, en ese caso deberemos asignar más Story Points (SP) a las nuevas US .
2-  Si nos comprometimos con una Velocidad que no somos capaces de cumplir, en el próximo Sprint deberemos comprometer menos SP a fin de asegurar la cobertura de testing acordada entre el Team y el PO.
¡ Lo importante es recordar que la Velocidad Real de un equipo son los SP necesarios para que una US esté resuelta!
Facebooktwitterredditlinkedinby feather

Leave a Reply

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>