¿Cómo gestionar la acumulación de productos con los principios DEEP?

El  Product Backlog  es una lista ordenada de todo lo conocido y necesario en el producto. Es una fuente única de demanda para cualquier cambio en el producto.

El propietario del producto es responsable de la acumulación de productos, incluido su contenido, disponibilidad y pedido.

La lista de cartera de productos nunca se completará. Los cambios en las necesidades comerciales, las condiciones del mercado o la tecnología pueden generar cambios en la lista de tareas pendientes del producto. Evoluciona con el desarrollo de productos y los cambios del entorno del proyecto. Los requisitos del proyecto nunca dejan de cambiar, por lo que la lista de tareas pendientes del producto es como un artefacto Scrum en constante evolución.

Los elementos de alta prioridad en la cartera de productos son detallados. Porque estos proyectos tienen más información y detalle, y por lo tanto tienen estimaciones más precisas.

Los proyectos de menor prioridad son los más grandes con detalles menos claros. A medida que el equipo obtenga información más detallada sobre proyectos de baja prioridad, se dividirán en proyectos más pequeños. El equipo de desarrollo es responsable de evaluar esos elementos en la cartera de productos de vez en cuando.

DEEP en la gestión de la cartera de productos

El backlog del producto enumera todas las características, funciones, requisitos, mejoras y correcciones necesarias para las versiones del producto. Los proyectos de acumulación de productos tienen los atributos de descripción (apropiadamente  detallada ), puntos de la historia ( estimaciones ) y pedidos ( priorizados ). Deben agregarse, eliminarse y actualizarse continuamente ( emergentes) en el backlog , y reflejar la comprensión del backlog del equipo de manera oportuna y adecuada.

Roman Pichler es el autor de Agile Product Management with Scrum Mentioned:

“Crear productos que aman a los clientes. Usamos la abreviatura de cuatro letras DEEP para describir las características de un buen Product Backlog”. es una abreviatura descriptiva de la calidad del producto de Backlog en Scrum, que significa:  Detallado apropiadamente,  E mergente ,  Estimado y  Priorizado .

Detallado Apropiadamente

Las historias cercanas a la parte superior de la cartera de productos estarán trabajando en el próximo  sprint , por lo que esos elementos deben estar lo suficientemente bien definidos para que el equipo trabaje en ellos de manera más productiva. Por lo general, las historias cerca de la parte superior de la cartera de productos son más pequeñas y más detalladas, pero se vuelven progresivamente más grandes y menos específicas más abajo en la lista de cartera de productos, como se muestra en la figura a continuación:

Estimado

Los artículos en el Product Backlog son estimados. Los elementos en la parte superior de la cartera de pedidos tienen estimaciones más precisas. Los elementos de menor prioridad se estiman en un nivel alto y se pueden volver a estimar a medida que el equipo obtiene más información.

Emergente

El Product Backlog no es estático, está en constante cambio. A medida que avanza el proyecto, se obtiene más y más información y conocimiento, y las historias de usuario en el Backlog del producto también se agregan, eliminan o reorganizan.

priorizado

En el Product Backlog ellos, cuanto más valiosa sea la entrada de mayor prioridad, arriba, menor será el valor de las entradas en el Product Backlog, menor será la prioridad, siguiendo en el Product Backlog. Los equipos siempre completan entradas de alta prioridad para garantizar que se maximice el valor del producto o sistema que se está desarrollando.

Resumen

DEEP es un concepto útil que se aplica en el  proceso de refinamiento del Product Backlog  , que implica el acto de agregar detalles, estimaciones y pedidos a los elementos del Product Backlog y mantenerlo en forma.

Durante el refinamiento de la cartera de productos, los artículos se revisan y modifican. El Equipo Scrum decide cómo y cuándo se realiza el refinamiento. El refinamiento normalmente no consume más del 10% de la capacidad del Equipo de Desarrollo. Sin embargo, los elementos del Product Backlog pueden ser actualizados en cualquier momento por el Product Owner o a su discreción.