El Product Backlog no es un evento en Scrum, pero tiene su lugar en la Guía de Scrum y por lo tanto en el marco Scrum. Por ejemplo, se recomienda que los miembros de los equipos de desarrollo no gasten más del 10% de su capacidad en el refinamiento de la cartera de productos.
Debido a que Scrum es un marco de trabajo y no es prescriptivo, los equipos decidirán cuándo y cómo refinar el contenido del backlog. Esto fomenta la auto-organización de los equipos, pero requiere un compromiso, apertura, respeto, enfoque y, a menudo, coraje para implementarlo.
Eso me suena a los Valores Scrum, así que vamos a investigar más a fondo:
Scrum llama a los ítems dentro del backlog simplemente Product Backlog Item (PBI), pero muchos Equipos de Scrum aplican una técnica popular llamada Historias de Usuarios para capturar los ítems.
Estos se dimensionan o estiman en los llamados puntos de la historia que siguen típicamente la secuencia de Fibonacci. Se han escrito muchos libros y artículos sobre historias y estimaciones de usuarios, que no quiero repetir en este momento.
En cambio, me gustaría centrarme en un escenario de esa técnica en particular, cuando los equipos estiman que la historia de un usuario es infinita. En el mundo de la escritura de historias de usuarios, estas se suelen llamar Épicas.
Por qué estas Épicas a menudo causan dolor de cabeza a los equipos Scrum.
Teniendo en cuenta que: a) el Refinamiento de la cartera de productos no es un evento, b) definir historias de usuarios es simplemente una técnica y c) Scrum no es prescriptivo, a menudo veo exactamente lo contrario cuando se trabaja con equipos:
- Reuniones semanales rígidas, con poca energía y participación.
- Debates acalorados sobre los términos, el significado y la aplicación de la técnica más que sobre la historia del usuario en sí.
- Herramientas que no se adaptan adecuadamente a la técnica de la historia del usuario.
Mi intención no es alejar a nadie de las historias de usuarios, sino que yo mismo las utilizo con bastante frecuencia. También quería asegurarme de que las épicas que a veces tienen una mala reputación no sean en general algo tan malo como parece.
Empecemos con la duración de la reunión de refinamiento, por ejemplo. La energía y la participación son a menudo bajas y se suelen realizar sólo con 60 minutos de margen aproximadamente, lo que casi nunca es tiempo suficiente para explorar cualquier épica o gran historia que se encuentre más abajo en la lista de prioridades.
Pero Sprint por Sprint, con el tiempo llegaremos a una historia que no haya sido desglosada y detallada. El resultado de esto puede ser una épica tan grande y desproporcionada que puede descarrilar la planificación del Sprint y dificultar la creación de un Objetivo Sprint bien enfocado.
Un típico anti-patrón es que las historias de los usuarios se extiendan a través de varios sprints. Con dos reuniones de 60 minutos en un Sprint de 2 semanas, también estamos muy por debajo del límite del 10% de capacidad.
Estas reuniones programadas podrían ser necesarias debido a la distribución de los equipos, pero una mejor facilitación, así como el aumento de la frecuencia de las reuniones, produciría una backlog de producto de mayor calidad.
Actividades durante el Refinamiento de la Cartera de Productos
El refinamiento del backlog de productos es de interés primordial para el Product Owner. Depende de este rol el tener un refinamiento efectivo del backlog. Para cada item que deciden presentar durante el refinamiento, se necesita tener una idea clara de lo que les gustaría conseguir.
En el vídeo de Henrik Kniberg, ‘Agile Product Ownership in a Nutshell’, se mencionan tres cosas que normalmente se hacen durante el Refinamiento de la cartera de productos. Acortar, estimar y redactar los criterios de aceptación de los ítems de la cartera de productos en colaboración con los grupos de interés…
Acortar
Como se ha dicho anteriormente, el propósito del refinamiento del backlog es conseguir que los items de la backlog estén listo para desarrollarse en el Sprint. Esto significa que las historias/items deben ser lo suficientemente pequeños/as para ser desarrollado en un Sprint.
Esto a veces puede requerir un poco de creatividad. Existe una plantilla muy útil para dividir historias y a mi parecer es una gran herramienta para ayudar a los equipos a explorar nuevas posibilidades para dividir las historias.
Para practicar hay un gran juego para que los equipos vean el valor de dividir historias, Alistair Cockburn creó el ejercicio Elephant Carpaccio.
Estimación
Una de las actividades más debatidas cuando los equipos aplican Scrum es el punto de estimación. Scrum simplemente establece que los ítems deben ser estimados, sin embargo, la forma de estimar se deja en blanco. Cualquier cosa que funcione será mejor que nada.
Primero, ¡siempre se puede estimar! Incluso si algo no está claro, se puede hacer una estimación (lo más probable es que sea algo grande). Asignar una estimación no es lo mismo que estar 100% seguro del tiempo que tomará hacerlo.
El perfeccionamiento de la backlog sería mucho menos difícil y requeriría mucho menos tiempo si todos los participantes están de acuerdo en que una estimación es incorrecta por defecto. No importa qué técnica se aplique. Si no se puede pasar de ese punto, cualquier técnica resultará igual de absurda.
Si consigues que todos estén de acuerdo en esto, entonces podrías considerar las siguientes técnicas.
- Tshirt Sizing
- Planning Poker
Criterios de aceptación
Añadir criterios de aceptación a una historia de usuario no es nuevo, hemos trabajado de esta manera durante décadas. Esta actividad se realiza junto con todo el equipo Scrum, preferiblemente durante el refinamiento. El nivel de detalle a la hora de redactar los criterios de aceptación depende de:
- La importancia de la historia en cuestión.
- El nivel de conocimiento y experiencia de las personas involucradas.
Conclusión
Las reuniones de refinamiento del backlog pueden ser muy eficientes cuando el Product Owner conoce más o menos el nivel de detalle que necesita el equipo de desarrollo. El mero uso de la plantilla de historia de usuario puede ser suficiente para que el equipo de desarrollo pueda empezar con el desarrollo. Un Product Owner eficiente debe dedicar menos tiempo a escribir los criterios de aceptación y más tiempo a la inspección frecuente y a la adaptación cuando la historia está en desarrollo.
Según mi experiencia, esto debería ser suficiente para empezar con el refinamiento de la cartera de productos.
