po ha podido trabajar y avanzar cada dia a la velocidad esperada y que a final de sprint se han conseguido realizar todos los puntos de historia planeados. Esto no quiere decir que el equipo no haya tenido impedimentos, pero si que indican que estos havian estado previstos en la estimación inicial, y que estos no han parado a todo el equipo, ya que cada dia se ha visto un avance. También indica que la separación en tareas ha sido buena, pudiendo definir tareas cortas que han significado un avance diario. Esto es lo que nos gustaria llegar a todos y por lo que tenemos que luchar.
Este BC lo que indica es que no se ha podido realizar toda la faena planificada, ni se ha modificado el sprint backlog para intentarlo. Este es un caso extremo ( se realiza un 10% de la faena ) pero es un tipo de BC que se suele dar. Las causas de este tipo de BC pueden ser varias: una mala estimación del sprint ( sobreestimación ), muchos impedimentos a lo largo del sprint, disminución del trabajo del equipo por enfermedad o similar, etc. Lo preocupante de este BC es que nadie ha hecho nada para intentar mejorarlo. Ni se han quitado los impedimentos, ni se ha reducido la carga de trabajo, ni se ha augmentado el equipo de trabajo. Un BC de este tipo tendria que hacer reflexionar tanto al grupo de trabajo ( ¿Qué les pasa a nuestras estimaciones? ) como al Scrum Master y al product owner ( ¿Porqué no he reaccionado a tiempo? ). Claramente es un BC a evitar.
Este BC ya nos gusta un poco más. El inicio del sprint es igual de malo que el anterior, pero a mitad de sprint el equipo ha visto que iba por mal camino. El descenso abrupto a mitad de sprint suele indicar que el product owner ha decidido sacar alguna história del sprint para intentar llegar a final de sprint de la mejor manera posible. También indica que se han eliminado impedimentos, ya que en la segunda parte del sprint el equipo avanza a una mayor velocidad. Es importante este tipo de modificaciones porque un escenario como el anterior deprime al equipo y este se pasa la mitad del sprint sabiendo que no se llegará al objetivo del sprint, cosa que puede hacer que su velocidad decaiga todavía más. Ayudando al equipo a poder cumplir con el objetivo del sprint, lo que ha hecho el product owner ( seguramente orientado por el scrum master ) ha sido mantener el equipo involucrado al 100% en conseguir el objetivo del sprint.