miércoles, septiembre 04, 2013

Tips para el Sprint Backlog: Primero las HU Riesgosas y luego las prioritarias

Hola a todos

Recordemos:

  • Sprint backlog: ítemes de backlog (en nuestro caso Historias de Usuario - HU) comprometidos a construir durante el sprint.


De las primeras cosas que aprendí en Scrum, al ver que un sprint fallaba fue:

Hacer de primero las HU más riesgosas y aunque no sean las prioritarias para el Product Owner (PO)


Razones:
  • si comienzas muy tarde a hacer la HU es probable que por sus dependencias o complejidad no la termines.
  • Obvio después de la(s) riesgosa(s) poner las HU que tengan más prioridad de forma que siempre estemos dando el máximo valor a medida que avanza el sprint.

Sugerencias:
  • Hacer ver al PO por que va esta(S) HU(s) de primero.- La verdad no es complejo-.
  • Debido a que esta historia va primero solicitar los insumos para hacerla, en caso que no estén,  poner una fecha máxima para la recepción de insumos, en caso contrario,  hacer ver que si no se reciben oportunamente la historia se cae (no se culmina), y esos puntos no se logran.
  • Lo ideal y recomendado es comenzar el sprint con los insumos (información, componentes, definiciones, etc) claros y resueltos para que el Sprint avance sin tropiezos.
  • Si una es HU riesgosa y se observa que la posibilidad de completarla es casi nula debido a su complejidad:
    • Definir un Spike (tarea dentro del sprint) con timebox definido (léase timebox=tiempo fijo) y objetivos definidos
    • Ese spike debe tener como objetivo eliminar la complejidad y adquirir el conocimiento necesario para lograr estimar y construir esa HU en el siguiente sprint
  • No tener muchas historias de usuarios riesgosas, a lo sumo 2 de un máximo de 7 HU (un sprint debería tener a lo sumo entre 6 y 8 HU), debido a que si son muchas el sprint puede ser un fiasco y no completar nada. (situación que viví y de la cual aprendimos como equipo)
  • Enfocarse y enfocar al equipo durante la ejecución del sprint en máximo 2 historias al tiempo de forma que se evacue siempre lo primero. Esto en Kanban se llamaría un limite de 2.

Saludos y abrazos ágiles a todos

Jorge Abad



No hay comentarios.:

Publicar un comentario