Sprint Planning en Combat Agile

A partir de este momento vamos a referirnos al Product Backlog como La Pila para que quede claro que es la representación de ese artefacto Scrum de la forma que se hace en Combat Agile.

Tanto GitHub como GitLab tienen la posibilidad con pequeñas diferencias entre ellos de representar La Pila como un listado ordenado de issues/incidencias y un tablero kanban. Me centraré en GitEIE porque será la plataforma que vamos a usar:

  1. Lo que conocemos como PBIs son cargados como issues en cualquier momento.
  2. Se agruparán los elementos de La Pila por Sprints utilizando los Hitos/Milestones: Ejemplo hitos
  3. Los elementos de La Pila que se implementarán en el Sprint (Sprint Backlog) se cargarán como issues siguiendo este modelo:
    Ejemplo incidencia
  4. Este proceso automatiza una serie de tareas. Por ejemplo, los milestones se pueden visualizar en el tablero (ver abajo). El Sprit Backlog son los elementos que pertenecen al milestone del Sprint actual. En la descripción del milestone se debe expresar el Sprint Goal.
  5. Así la prioridad de los elementos de La Pila viene establecida por el milestone al que pertenecen y dentro de cada milestone se ordenan los elementos por prioridad descendente en su columna:
    Ejemplo tablero
  6. Los elementos deben tener visible su estimación en tiempo para ayudar a agruparlos. Los issues que formen parte del Sprint Backlog deben tener un tamaño de un día (8 horas) o menos.

Echa un vistazo a los pasos iniciales cargando la primera incidencia y viendo estos elementos en video.