¡Compártelo!
Share on facebook
Share on google
Share on twitter
Share on linkedin

Artefactos Scrum: el Sprint Backlog

Hoy volvemos a la carga con la segunda entrega sobre los artefactos en Scrum: el Sprint Backlog (dejo por aquí el enlace a la primera entrega). Este artefacto, que cualquier equipo Scrum usa en su día a día, es uno de los grandes desconocidos. No son pocos los debates que se mantienen al respecto sobre a quién pertenece, qué debe contener, cuál es su finalidad, etc. En esta entrada intentaremos arrojar luz sobre estos temas y comentar algunas de las buenas prácticas que deberíamos tener.

¿Qué es el Sprint Backlog?

El Sprint Backlog no deja de ser un conjunto de tareas del Product Backlog que se han seleccionado para el Sprint (por ello, esta denominación especial). Si vamos un poco más allá de esta definición básica encontraremos que el Sprint Backlog es realmente un plan. Un plan para entregar incremento de producto (otro artefacto, lo veremos en siguientes entregas) y, por supuesto, alcanzar el objetivo de Sprint (Sprint Goal).
Otra definición que se le podría dar es la de «previsión». Una previsión de qué funcionalidades estarán en el próximo increment y, dependiendo de la definición de «done» del equipo, esté disponible como software funcionando de una forma u otra.

Sprint backlog

Fuente: Scrum.org

Buenas prácticas

A continuación enumeramos diferentes consejos y/o buenas prácticas a la hora de crear y gestionar el Sprint Backlog:

  1. Se recomienda incluir al menos una acción que haya salido de la retrospectiva del Sprint anterior que pueda tener un gran impacto en el proceso del equipo. De esta forma, nos aseguraremos de cumplir con uno de los pilares básicos de Scrum de inspeccionar y adaptar. Comúnmente las acciones se intentan cumplir en paralelo a la ejecución del Sprint, pero la realidad es que la mayor parte de las veces no se llegan a cumplir. El día a día o un Scrum Master que no vela porque estas acciones se vayan implementando en tiempo y forma (en su labor de conseguir y optimizar todo el proceso Scrum) son los principales motivos que hacen que estas acciones caigan en saco roto.
  2. Debe ser la herramienta central sobre la que se desarrolle la Daily. El Sprint Backlog debe tener los detalles suficientes como para que todo el equipo entienda los cambios y progresos realizados y enfocar las daily como, digamos, «mini-plannings», donde revisar si sigue siendo alcanzable o no el objetivo del Sprint o es necesario acciones para asegurar esto.
  3. Siguiendo la práctica anterior, el equipo debe ir gestionando las prioridades con el foco en conseguir cumplir el objetivo del Sprint. Por ello, tiene la potestad para modificarlo durante el Sprint en caso de que se detecten nuevas necesidades o nuevos aprendizajes sobre el trabajo a realizar para conseguir este objetivo. Esto siempre ha sido un tema entre la polémica y el debate, pero a día de hoy, lo que nos indica la guía Scrum es que el equipo de desarrollo es el único que puede modificar el Sprint Backlog durante el Sprint. Es más, indica que pertenece únicamente al equipo de desarrollo.
  4. En esta línea, si el equipo de desarrollo detecta que un trabajo no incluido en este artefacto es necesario para conseguir el objetivo, debe añadirlo. Y en el lado opuesto, si el equipo acuerda que hay trabajo del Sprint que ya no es necesario para conseguir el objetivo, puede y debe eliminarlo. De esta forma, se asegura por el propio equipo que el trabajo a realizar durante ese Sprint es justo el necesario para cumplir el Sprint Goal, adaptándose a los cambios que vayan surgiendo.
  5. El equipo debe tener total visibilidad sobre este artefacto y, más allá de medir la famosa velocidad o cuanto estamos entregando, es importante medir la cantidad de trabajo pendiente. En las dailys se tendrá que ir actualizando el progreso y elegir según trabajo restante, días del Sprint y objetivo. Por ello, es importante tener siempre actualizado este backlog, ya que determinará los siguientes pasos día tras día.

Conclusión

Hemos visto la gran relación que existe entre este artefacto y el objetivo del Sprint (del que hablaremos en futuros posts). Todas las piezas de la máquina que forman el marco de trabajo Scrum son importantes y el proceso completo solo funcionará si se implementan y se usan correctamente.
Como resumen, el Sprint Backlog es un artefacto muy potente por y para el equipo y, como todos sabemos, «un gran poder conlleva una gran responsabilidad».

Artículos relacionados

Como hacer un value stream mapping

Cómo hacer un Value Stream Mapping: ejemplo de desarrollo de software

En el artículo de hoy vamos a explicar cómo aplicar la técnica de Lean llamada Value Stream Mapping (VSM), de forma práctica y con un ejemplo real de desarrollo de software. No confundir con Value Stream Management, aunque están muy relacionados como veremos. ¿Qué es

Límites WIP Jira

Cómo configurar límites WIP en Jira

En este videotutorial te mostramos cómo configurar límites WIP en una instancia de Jira. Pero antes de ello, te ayudamos a conocer qué es WIP y por qué interesa limitarlo. Qué es WIP WIP, work in progress o trabajo en proceso, en español, se refiere

Descubriendo el poder de Pair Programming

Muchos de los que me conocen ya saben que más que Scrum, Kanban… si hay algo que realmente creo que funciona es eXtreme Programming. Es por ello que en Profile intentamos combinar las diferentes prácticas de las que nos habla XP con otros frameworks ágiles.