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.
Este BC puede llegar a dar información tan negativa cómo el segundo que hemos visto. Si vemos un BC cómo este no tenemos porque pensar que somos los mejores desarrolladores del mundo, lo que tenemos que pensar es que es que también hemos estimado mal, y es prácticamente tan malo sobreestimar como infraestimar. Es importante que el equipo pueda hacer estimaciones realistas y que se cumplan los objetivos del sprint. De todas maneras, ni que sea por la imagen exterior que se dá, siempre es mejor este tipo de escenario que no un escenario de sobreestimación, ya que este último dá mala imagen del equipo. En el caso que el equipo consiguiera el mismo incremento de valor tanto en el escenario de sobreestimación como en este, la imagen del equipo es mucho mejor en este. Como se puede ver al final el equipo ha decidido añadir tareas de las no planificadas al sprint actual.
3 comentarios:
Cuidadito con el 3er burn-down. Tu interpretación de que la aceleración del final se debe a que habeis eliminado impedimentos PUEDE ser la buena... la otra posible es que el equipo, viendo cerca (y posible) un final exitoso, ha sacrificado la calidad.
En nuestro caso, cada vez que tuvimos un burn-down así y lo analizamos, resultó ser lo 2º :-(
Respecto a no haber visto nunca el burn-down perfecto, puedes ver uno aquí: http://jordionsoftware.blogspot.com/2009/10/charla-en-barcelona-php-conference-2009.html
Espero haberte puesto dientes largos :-)
Lo conseguimos haciendo un cambio de perogrullo: reduciendo la cantidad de trabajo planificada para el sprint!
Hay que decir, pero, que para conseguir hacer ese cambio de perogrullo, hubo que hacer otro mucho más importante: separar realmente los roles de PO y SM para reducir las presiones sobre el SM para meter más tema en cada sprint.
Hola Jordi,
ante todo, gracias por tu comentario.
Efectivamente lo que dices es totalmente cierto. Cuando hicimos el artículo pensamos en una situación de Scrum ideal, es decir, un equipo donde la frase "la calidad no es negociable" se lleve a rajatabla. Pero efectivamente no pasa siempre esto, es más, seguramente es lo menos común. Así que tu puntualización es totalmente acertada.
Nosotros, curiosamente, también estamos haciendo este cambio de roles en nuestra empresa. Esperemos que tenga el mismo efecto!
Y la verdad es que si, me has puesto los dientes largos :P
Saludos!
Tengo una duda, en una situación en la cual se usan únicamente puntos de historias y las tareas que tiene cada historia ya no se estiman en horas, obviamente lo que quemas son puntos de historias cada que se termina uno de estas. En el caso del tercer BC, si sacaste una historia, al final quemas esos puntos como si realmente el equipo lo hubiera trabajado? no me queda claro como es que al final si se saco una historia el gráfico tiene esa alineación, o es que volvieron a rehacer el BC teniendo en cuenta solo los puntos de historia que entrarían después del "recálculo" de historias. Gracias.
Publicar un comentario