Product backlog

Product Backlog

<Apertura/> (Minuto 0:00 - 1:00)

En la agilidad, tener una visión clara y unos objetivos definidos es clave para que un equipo se mantenga enfocado y logre sus metas. Hoy, nos sumergiremos en uno de los artefactos fundamentales de Scrum: el Product Backlog. Este artefacto es la lista maestra de todo lo que queremos lograr con nuestro producto y nos ayuda a tener una visión compartida de hacia dónde vamos y cómo estamos generando valor.

Ideas clave (Minuto 1:00 - 4:30)

El Product Backlog es una lista emergente y ordenada de todo lo que se necesita para crear y mejorar el producto. El Product Owner es la persona responsable de gestionar este artefacto de forma eficaz.

Cada elemento del Product Backlog tiene atributos como una descripción, orden (prioridad), estimación y valor (valor para el negocio). El Product Backlog nunca está completo, evoluciona continuamente a medida que el producto y el entorno en el que se utilizará evoluciona.

El Product Goal (Objetivo del Producto) es el compromiso del Product Backlog. Describe un estado futuro del producto que puede servir como un objetivo para que el Equipo Scrum realice su planeación.

El refinamiento del Product Backlog es la actividad continua de descomponer y definir los elementos de la lista en ítems más pequeños y precisos. Es una actividad continua para agregar detalles, estimaciones y orden a los elementos del Product Backlog. No es un evento de Scrum, sino una actividad que ocurre durante el Sprint

El Product Owner y los Desarrolladores colaboran en el refinamiento, los elementos se examinan y revisan para garantizar que son adecuados para futuros Sprints.

Práctica (Minuto 4:30 - 6:00)

Para entender cómo priorizar un Product Backlog, utilizaremos la técnica de priorización de MoSCoW. Esta técnica nos ayuda a clasificar los elementos de la lista de trabajo según su importancia para el éxito del producto. La clasificación es:

• Must have (Debe tenerlo): Funcionalidades esenciales que el producto debe tener.
• Should have (Debería tenerlo): Funcionalidades importantes, pero no vitales. El producto podría funcionar sin ellas.
• Could have (Podría tenerlo): Funcionalidades que son deseables pero opcionales. Se pueden incluir si el tiempo y los recursos lo permiten.
• Won't have (No lo tendrá): Funcionalidades que el equipo ha decidido no incluir en el futuro cercano.

Actividad:

Vamos a usar esta técnica para priorizar un Product Backlog de nuestra aplicación de idiomas.

• Sistema de gamificación
• Crear una cuenta
• Guardar progreso
• Conversación con un bot
• Foro comunitario

Apliquemos esta técnica al caso de la aplicación de aprendizaje de idioma en inglés:

1. Must Have: Funcionalidad para que los usuarios puedan crear una cuenta y guardar su progreso. Sin esto, la aplicación no tiene sentido.
2. Should Have: Un módulo de práctica de conversación con un bot de IA para mejorar la fluidez.
3. Could Have: Un foro comunitario donde los usuarios puedan interactuar entre ellos y compartir consejos.
4. Won't Have: Un sistema de gamificación con premios y medallas para los usuarios. Esto se puede dejar para un futuro lejano.

Cierre (Minuto 6:00 - 7:00)

Como vimos, el Product Backlog es una herramienta viva y dinámica, y tener herramientas de priorización como MoSCoW  que ayuda al Product Owner a mantener claras las prioridades.

A continuación, dado el caso de estudio que venimos desarrollando, identifica una primera versión de product backlog ¿qué elementos identificas que hagan parte de la lista de producto? ¿cómo priorizarías el product backlog con la técnica MoSCow?. Te invitamos a desarrollar este reto y nos vemos en la siguiente clase con un concepto nuevo: Historias de usuario.