Lista de producto o Product Backlog
Lista de producto o Product Backlog
Lista de Producto o Product Backlog
El Product backlog (PB): Llamado Lista de Producto, es una lista ordenada de todo lo que se conoce y que es necesario para el producto..
Es la única fuente de requisitos para cualquier cambio a realizarse en el producto, el responsable de este artefacto es el Product Owner y es el único que puede modificarlo. Se escribe en lenguaje de negocio.
Es un artefacto que contiene Itemes del Product Backlog (PBI), que son los que se implementarán, se ordenan por orden de valor de negocio, siendo el más valioso el primero que se debe implementar. Los PBI pueden ser épicas, features o historias de usuario. Las primeras son genéricas, tan grande que no alcanzan a ser desarrolladas en un Sprint, las segundas medianas y las terceras muy detalladas, con criterios de aceptación que permiten identificar de manera objetiva cuando se cumplen y cuando no. Es necesario refinar las épicas a features y estos a historias de usuario antes de que entren a desarrollarse en el Sprint.
Un PB es DEEP. esto significa:
D: Detallado: Que contenga historias de usuario que sean detalladas suficientemente. Ver más detalles de las historias de usuario en Sprint Planning.
E: Estimado: Que los ítemes del Product Backlog se puedan estimar, para esto deben ser detallados lo suficientemente.
E: Emergente: Esto significa que el PB nunca dejará de cambiar, estará constantemente evolucionando, debido a que las necesidades del mercado están constantemente cambiando.
P: Priorizado: Que los ítemes del product backlog se puedan priorizar por valor de negocio.
La lista de producto en general necesita de una reunión de refinamiento, esta se realiza dentro del sprint y se hace ondemand y de manera recurrente con los integrantes del equipo de scrum. En general se utiliza para refinar las historias de usuario que vienen en el siguiente sprint, con el fin de que lleguen a la reunión de planificación más claras para el equipo, el product owner y los mismos stakeholders.
Lo ideal es que no consuma más del 10% del esfuerzo del team dentro del sprint, es decir si hay un team de 5 personas, que trabaj 8 horas diarias y el sprint es de 2 semanas (10 días), sería:
5 x 8 x 10 = 400 horas, que es la capacidad total teorica del equipo, sin embargo en la práctica es imposible trabajar las 8 horas, para partir podría multiplicarse por un factor de 0,7, que permite tener una capacidad total dentro del sprint más realista:
400 x 0,7 = 28 horas, que sería la estimación total de horas disponibles para un equipo de 5 personas en 10 días de sprint. Por ende entre todos lo ideal es que no se gasten más de un 28 horas de trabajo de todo el equipo dentro del sprint.
Si nunca has visto un Product Backlog, puedes ver el siguiente ejemplo de un hotel:
En la columna de la derecha aparece la prioridad, siendo 1 la mayor, la que agrega el mayor valor de negocio.
Ver video: