.

4 Claves para componer un Backlog de Producto de calidad

¿Quieres conocer las claves para desarrollar un buen Backlog de Producto? DEEP; este sencillo acrónimo te permitirá recordar las características en base a alas cuales desarrollar un Backlog de Producto de calidad.

planificando

Si el acrónimo INVEST se emplea para determinar la calidad de una buena historia de usuario, el acrónimo DEEP se emplea para el Backlog de Producto. Este acrónimo resume las cuatro características principales que debe incluir un buen Backlog de Producto: Detailed appropriately, Emergent, Estimated  y Prioritized. Veamos en qué consiste cada una de ellas.

Nivel de detalle apropiado

El Nivel de detalle apropiado, en ingles Detailed appropriately, hace referencia a que no todos los elementos del Backlog del Producto deben tener el mismo grado de detalle. Al respecto, los elementos de la parte de arriba, aquellos con los que empezaremos a trabajar a más corto plazo deberán estar más detallados, y ser más pequeños en tamaño (respecto a los puntos de historia). De la misma manera, los elementos de la parte de media y baja del Backlog de Producto estarán menos “trabajados”; tendrán menos detalle y su estimación en puntos de historia estará representada por valores más altos.

Por ejemplo, si tomamos como referencia una historia de usuario de tipo Épica, esta se desglosara y las historias de usuario la componen se detallarán más conforme se avance hacia la ejecución de la misma en el proyecto.

¿Cuándo desglosar las historias de usuario “más grandes”?

La actividad de desglosar y detallar las historias de usuario del Backlog de Producto se conoce en scrum como refinamiento del Backlog de Producto.

Recuerda que nos encontramos en el marco de un enfoque Ágil y por tanto debemos evitar realizar por anticipado tareas que no generen valor. Pudiera darse el caso que dedicásemos a tiempo a refinar historias de usuario que nunca lleguemos a implementar. Por otro lado, no prestar la debida atención al refinamiento afectará de manera negativa a nuestra planificación y al desarrollo de la iteración.

Emergente

El Backlog de Producto es un elemento vivo: nunca está completo, o dicho de otro modo está en constante evolución. El feedback que recibimos del cliente es el elemento esencial que marcha dicha evolución.

Es por eso que una de las características esenciales del Backlog de Producto es que es emergente, en tanto que su estructura surge a lo largo del tiempo y se mantiene en constante evolución. Elementos que forman parte hoy puede desaparecer mañana, de la misma manera que mañana puede incorporarse otros nuevos.

¿Cómo se mantiene un Backlog de Producto emergente?

La clave de los enfoques Ágiles consiste en mantener el alcance del proyecto dinámico (flexible). Para ello, debemos mantener un alcance abierto y asegurarnos que el mismo evoluciona en base al feedback del cliente.

Estimados

Todos los elementos del Backlog de Producto deben estar estimados (Estimated). Es decir, deben incluir una estimación del esfuerzo necesario para llevarlo a cabo. Dado que los elementos de la parte alta del Backlog de Producto serán más pequeños y detallados, su valor en puntos de historia será más pequeño que los de la parte media y baja.

¿Cómo estimar los elementos del Backlog de Producto?

Lejos de estimar los elementos del Backlog de Producto en base a horas hombre, incluso a horas hombre ideales, en los enfoques Ágiles se emplean a menudo los puntos de historia. Los puntos de historia son una medida de esfuerzo relativo que considera el esfuerzo necesario para completar una tarea en comparación con otra.

Un consejo: es posible que por su tamaño y poco grado de concreción, no puedan estimarse los elementos de la parte más baja del Backlog. En este caso, podría dejarse sine estimar o emplear otra técnica en lugar de los puntos de historia. Por ejemplo las tallas de camiseta (S,M,L,XL,…).

Priorizado

La propia definición de Backlog de Producto establece que se trata de una lista priorizada de los elementos que forman parte del alcance del proyecto. Sin embargo, al igual que ocurre con las estimaciones, es posible que no sea posible (no conveniente) priorizar todos los elementos del Backlog de Producto.

¿Cómo priorizar los elementos del Backlog de Producto?

Es responsabilidad del Propietario del Producto priorizar el Backlog del Producto. Los elementos que lo componen estarán priorizados en función de su valor para el cliente, pero corresponde al Propietario del Producto decidir como calcular ese valor.

Un consejo: será útil priorizar los elementos de la parte de arriba, aquellos que se desarrollaran próximamente. AL contrario, no sería  necesario invertir ningún esfuerzo en aquellos de la parte más baja.

Post relacionados

Scrum: tres en uno Aunque Scrum es el marco de trabajo Ágil más conocido para desarrollar y gestionar proyectos de software, es mucho más que eso. Al respecto, Jeff Su...
¿Qué es el Marketing Ágil? El Marketing Ágil (Agile Marketing) es una  aproximación al marketing inspirada en el enfoque Agile empleado en el desarrollo de software. Igual que e...
La planificación en los entornos Ágiles  ¿Quién dijo que en los entornos Agiles no se planifica? Muchos piensan que en los entornos Agiles no hay planificación, no se diseña, no hay discipl...

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

AUTOR:  Juan Luis Vila Grau

PRINCE2® practitioner, Scrum Master (PSMI), EXIN Agile Scrum Foundation, AgilePM® Foundation, Management_of_Risk (M_o_R®) Foundation. and an enthusiastic of Agile management. Especialistas en técnicas participativas para la gestión de proyectos, y en el Enfoque del Marco Lógico (EML). Faclilitador certificado en el método LEGO® Serious Play®

Utilizamos cookies de terceros para mejorar nuestros servicios. Si continúa navegando, considera que acepta su uso. Más información aquí.  CERRAR