El Sprint Backlog suele generar bastantes dudas en cuanto a su gestión. En ocasiones se convierte en un arma arromadiza que los stakeholders, el Producto Owner o incluso el Scrum Master utilizan para controlar el equipo. ¿Es esta su función?
Qué es el Sprint Backlog
El Sprint Backlog es la suma de tres elementos: El forecast, el Sprint Goal y las tareas del Sprint.
Forecast: Durante el Sprint Planning, el equipo de desarrollo selecciona las tareas del backlog que prevén que podrán entregar durante el Sprint. Estos PBI permanecen visibles y transparentes a todos los miembros del equipo para facilitar el foco y la conversación acerca de lo que se está consiguiendo durante el Sprint.
Sirve para mantener la transparencia sobre el trabajo que está realizando el equipo durante el Sprint.
Sprint Goal: Asimismo, después de seleccionar el Forecast, el Product Owner junto con el equipo de desarrollo idean una meta común a todos esos Product Backlog Ítems, que proporcione una dirección única. En caso de duda sobre prioridades, el equipo acude al Sprint Goal para entender mejor el contexto del trabajo que están haciendo.
Las tareas del Sprint: Estas tareas, generalmente asociadas a los PBIs seleccionados durante el Sprint Planning, son la implementación técnica para conseguir entregar los PBIs y que éstos a su vez consigan el Sprint Goal que el equipo, junto con el Product Owner ha decidido.
Para quién es el Sprint Backlog
Quizás éste sea uno de los problemas, la propiedad del Sprint Backlog. Aunque los Stakeholders, el Product Owner o el Scrum Master puedan ver el Sprint Backlog, éste es propiedad del Equipo de Desarrollo. Únicamente de ellos.
El Equipo de Desarrollo es responsable de mantener, actualizar y reflejar la realidad del Sprint como ellos mejor decidan. Sea un tablero físico o un tablero digital, es su prerrogativa.
Además, el Sprint Backlog sirve para dimensionar el riesgo y tener una conversación, no para llenar capacidad (para eso tenemos el Sprint Planning). Así evitamos que por querer cargar más de lo que podemos en el Sprint, al final los ítems importantes queden sin hacer.
¿Se puede cambiar el Sprint Backlog?
Respuesta corta: Sí. Respuesta larga: No solamente puede cambiar sino que lo normal es que cambie varias veces durante el Sprint. Esto es un reflejo de la complejidad del desarrollo de Software, en el que descubrimos diferentes problemas que tenemos que resolver, y por tanto reflejar, en nuestro Product Backlog.
¿Puede cambiar con cosas que no tengan que ver con el Sprint? Sí, siempre y cuando se acuerde con el Product Owner y aceptando el riesgo que supone tener un WIP muy alto.
Cuando tenemos un equipo de 7 personas en el que cada uno tiene su propias tareas, nos enfocamos en la eficiencia. Sin embargo, no esperemos que colaboren para resolver impedimentos o problemas cuando surjan. Al fin y al cabo, cada uno está haciendo su trabajo, ¿no?
De nuevo, el Sprint Backlog es propiedad del equipo de desarrollo y ellos decidirán en qué pueden trabajar. Scrum dice que el trabajo que hay que hacer durante el Sprint irá actualizando y refinándose conforme pase el mismo.
Visualizando el trabajo: El Burndown
En 2013, se eliminó la práctica del Burndown de la guía de Scrum. La razón es evidente. Scrum ha ido evolucionando hacia una posición más agnóstica en lo que herramientas y prácticas se refiere.
El motivo es que lo que puede funcionar para un equipo Scrum, no tiene por qué funcionar para otros equipos Scrum. En sus primeras versiones, Scrum estaba muy enfocado en las prácticas de ingeniería y la orientación a objetos.
Conforme ha ido evolucionando, ha ido eliminando este tipo de sugerencias y centrándose en lo que realmente tiene valor: Las reglas del juego.
Así, el equipo de desarrollo puede utilizar la herramienta que quiera para visualizar su trabajo en el Sprint Backlog. Algunos equipos eligen introducir un sistema del método Kanban con un tablero. Otros deciden quedarse con el Burndown. Otros prefieren ver horas/días restantes de trabajo.
En cualquier caso, la decisión tiene que venir del equipo, nunca del Scrum Master o del Coach.
Estimaciones en el Sprint Backlog
Otra cuestión básica es si se deben estimar las tareas en el Sprint Backlog. La respuesta es: ¿Cuál es el valor?
Las estimaciones existen para promover una conversación entre miembros del equipo, no para hacer predicciones sin fundamento. Las empresas que utilizan estimaciones en story points u horas para hacer predicciones están más del lado del chamanismo que del trabajo profesional. Existen muchas otras técnicas para estimar y tener métricas de desarrollo de producto.
La respuesta es clara: Lo que el equipo de desarrollo decida. Usualmente será evitar las estimaciones.
Físico o digital
Llegamos al quid de la cuestión. Si has llegado hasta aquí, probablemente te habrás dado cuenta de que la pregunta ya no tiene mucho sentido. La mayoría de las peticiones para mantener el Sprint Backlog de forma digital tienen más que ver con controlar que con facilitar la transparencia.
Mi experiencia es variada. Algunos equipos con los que he trabajado han decidido mantenerlo completamente digital. Con la pérdida de visibilidad -que no transparencia- que esto supone.
Otros equipos han decidido mantener un tablero físico y solamente marcaban los PBIs como finalizados, dejando las tareas y el Sprint Backlog fuera de la herramienta.
En cualquier caso, de acuerdo a Scrum, lo que el Equipo de Desarrollo decida.