Sprint Backlog ¿Qué es? ¿Quién lo gestiona?
30/06/2022
El Sprint Backlog es mucho más que una lista de PBIs, segun la guia Scrum, el sprint Backlog consiste en un Para Qué, el propósito del Sprint y eso nos lo da el Sprint Goal, el Qué , que será la previsión del Sprint o los elementos seleccionados para poder alcanzar ese Para qué y por último el Cómo, que será el Plan accionable que utilizarían los developers para entregar el incremento. 
Como gestionar un buen Sprint Backlog por parte del equipo scrum y como crearlo con un plan de consecucion del sprint goal

El Sprint Backlog es un plan que elaboran los desarrolladores durante la Sprint Planning, los desarrolladores son quién realmente hacen el trabajo y por lo tanto quien debe de crear dicho plan. Y nadie debe de asignarles tareas ni Product Owner y tampoco el Scrum Master

Como beneficios de un buen Sprint Backlog podemos encontrar el aporte de la transparencia en todo momento, transparencia sobre el trabajo realizado y sobre todo la cantidad de trabajo que falta por hacer para poder alcanzar el Sprint Goal

Ejemplos de Sprint Backlog

No hay un estándar sobre como tener un Sprint Backlog, pero sí que podemos realizar algo parecido a la foto siguiente:

Como gestionar un buen Sprint Backlog por parte del equipo scrum y como crearlo con un plan de consecucion del sprint goal

Para poder crear algo así durante la Planning, podemos realizar las siguiente preguntas:

  • ¿Con qué elementos podemos empezar?
  • ¿Cuál dejar para el final del Sprint?
  • ¿Hay algunas dependencias internas, técnicamente o funcionalmente?
  • ¿Existen algunas dependencias externas que no están resueltas y que pueden llegar a bloquear el avance de algún PBI?
  • ¿Qué tareas del primer PBI hay que abordar?
  • ¿Quién del equipo puede acometer esas tareas?
  • ¿Tiene sentido que trabajemos en varios PBIs a la vez? ¿o mejor poner foco en uno y luego el otro?
  • ¿Tiene sentido hacer Pair Programming en todos los PBIs?
  • ¿Tiene sentido hacer Mob Programming en algunas de las tareas?
  • etc.

No hay un único plan para todo, lo importante es buscar la manera de crear un plan según el objetivo que tiene el equipo y sobre todo ser capaces de inspeccionar y adaptar el Plan Daily a Daily

 Quien debe gestionar el Sprint Backlog

El Sprint Backlog es propiedad de los developers en el Scrum Team, nadie más que ellos puede añadir, quitar o modificar PBIs en este artefacto. ¿Esto quiere decir que podemos cambiar el contenido del Sprint Backlog durante el Sprint una vez arrancado? pues si.

¿Puede cambiar el Sprint Backlog durante el Sprint?

En el mundo del desarrollo de software la incertidumbre está al orden del día, desconocemos más que conocemos. Y es muy normal que el equipo descubra cosas que no tenía claras, aprenda cosas nuevas, o simplemente, se dé cuenta que algo que pensó al principio que era fácil resulta que es complicado o al revés. 

Hay que pensar que es posible que después de la planning el equipo se dé cuenta que se les olvidó una feature importante y necesaria para alcanzar el Sprint Goal (este si que no debe cambiarse, su alcance si), entonces lo que tienen que hacer es renegociar el alcance con el Product Owner y ajustar su Sprint Goal.

Al final el equipo conforme va aprendiendo durante el sprint, puede eliminar, añadir o modificar ciertos PBIs. Y solo los desarrolladores pueden hacerlo, ni el PO ni el SM tienen que gestionar el Sprint Backlog del equipo.

La adaptación y el Sprint Backlog

Creo que ya queda claro que el Sprint Backlog debe de inspeccionarse y debe de adaptarse durante el Sprint, pero, ¿Que hay que inspeccionar? ¿Cómo hay que hacer? y ¿Cuándo hay que hacerlo? vamos paso a paso.

El Sprint Backlog se crea en la Sprint Planning e incluso ahí se puede adaptar conforme se esté creando el Plan para alcanzar el Objetivo del Sprint. Otro evento ideal para inspeccionar y adaptar el Sprint Backlog es el Daily Scrum, para ello es importante que el Sprint Backlog ofrezca una imagen real del estado del Sprint para conseguir el objetivo.

Cuando el Sprint Backlog ofrece una foto real de la situación del Sprint y el progreso del equipo, permite a los desarrolladores ajustar y adaptar lo que consideran necesario para aumentar la probabilidad de alcanzar sus objetivos, estas actualizaciones pueden ser como:

  • El trabajo que se ha terminado o el que se está empezando
  • Los items que se han bloqueado
  • Algún trabajo que se acaba de identificar
  • Elementos que por varios motivos se consideran no necesarios para el Sprint
  • Algún tipo de riesgo que se identifica
  • etc.

Estos ajustes se realizan para poder alcanzar el Sprint Goal como equipo.

Más info sobre Sprint Backlog en ScrumdotOrg

Si te ha gustado, dale a me gusta y ayudame a compartirlo 🙂 

Un saludo y hasta la próxima 

¿Te ha gustado este contenido?

¡Valora este contenido!

Promedio de puntuación 5 / 5. Recuento de votos: 1

Hasta ahora, ¡no hay votos!. Sé el primero en puntuar este contenido.

Artículos relacionados

Publicaciones recientes

Apúntate a la newsletter

Apúntate a la newsletter

Manténte informado sobre todo lo relacionado con Agile Product Management, Scrum, Management 3.0 y Kanban

¡Mensaje enviado!