Guía Scrum | 18. ¿Qué es el Product Backlog?

El Product Backlog es la única fuente de tareas realizadas por el Scrum Team. Es una lista de funcionalidades y mejoras planificadas del Producto. Su forma es modificable y no se completarán todas las tareas incluidas en el Product Backlog. Evoluciona durante las discusiones con las partes interesadas. También se mejora constantemente. Significa que cuanto más se acerca la fecha límite, más detallada se vuelve una tarea.

¿Qué es la cartera de productos? - Tabla de contenido:

1. Introducción
2. ¿Qué contiene el Product Backlog?
3. La forma del Product Backlog
4. Mejora de la cartera de productos
5. Resumen

Introducción

Product Backlog es el más grande de los artefactos de Scrum. Refleja el estado del trabajo en un Producto en relación con el Objetivo del Producto. Por otro lado, cuando se completa el trabajo en un Producto, su Backlog se convierte en una lista completa de las tareas realizadas por el Equipo Scrum para crear el Producto. Sin embargo, no contiene soluciones técnicas detalladas.

¿Qué contiene el Product Backlog?

Product Backlog se crea durante las reuniones del Product Owner con las partes interesadas. El propietario del producto es el único propietario y la persona responsable de esta fuente de tareas.

El lenguaje comercial caracteriza las entradas en el Product Backlog. En otras palabras, describen el valor del Producto desde el punto de vista de los Stakeholders.

Las descripciones de tareas incluidas en la lista de tareas necesitan coherencia y claridad. Contienen funciones y mejoras del Producto que normalmente se presentan en forma de Historias de Usuario a las que dedicamos una entrada aparte. Aquí solo mencionaremos que estas son descripciones de funcionalidades parciales del producto respondiendo las preguntas sobre los siguientes temas:

• El alcance de las modificaciones del Producto
• El propósito de modificar el Producto
• El tipo de usuario para el que surge esta modificación

La forma del Product Backlog

El orden de las tareas incluidas en el Product Backlog cambia a medida que se desarrolla el Producto. Mientras trabaja en él, el Equipo Scrum da forma y mejora sus funcionalidades. Al encontrar obstáculos, sus acciones implementadas permiten a todos pensar y definir futuras soluciones adecuadas, y estas también cambiarán de acuerdo con más obstáculos imprevistos. Por lo tanto, no hay un orden claro y definido de acciones, todo es cambiable. La mejora del Product Backlog está encaminada a su continua actualización y preparación para las próximas tareas. Por esta razón, es continuo.

Las tareas con una fecha límite lejana suelen ser totalidades grandes y genéricas. Su descripción no contiene detalles, sino solo un resumen de la funcionalidad que debe realizarse. También es posible encontrar tareas entre ellas que nunca terminarán.

Las entradas en el Product Backlog pueden presentar soluciones alternativas. Y también las ideas del Cliente que pueden quedar obsoletas, no rentables o por alguna otra razón nunca entran en la fase de implementación. Es por eso que el Product Backlog a veces se llama en broma la "lista de deseos del cliente".

Otra razón para los cambios en la forma del Product Backlog es la redefinición de soluciones. A veces resulta que un determinado problema ya se ha resuelto al crear la funcionalidad de otro producto. O la funcionalidad esperada se ha vuelto redundante debido a cambios en otras soluciones.

Una de las actividades básicas durante la mejora del Product Backlog es dividir las tareas contenidas en el Product Backlog en partes. Gracias a esto, el esquema general de funcionalidad se presenta en forma de unidades más pequeñas, más detalladas y definidas con precisión.

Las tareas diseñadas para una implementación más cercana se vuelven más detalladas. También se vuelven más pequeños y contienen detalles de las soluciones. Los detalles emergen durante el desarrollo del Producto. Y gracias al conocimiento del estado actual del Producto y las expectativas actuales de los Stakeholders, el Product Owner complementa las próximas tareas con su descripción, orden y tamaño. Luego, selecciona las tareas mejor descritas para el próximo Sprint Backlog.

Mejora de la cartera de productos

Mientras trabaja en un Producto, el Propietario del Producto modifica y detalla el Product Backlog en cooperación con el Equipo de Desarrollo. Siguiendo las sugerencias del Dueño del Producto, durante la Planificación del Sprint, el equipo selecciona las funciones para implementar desde el Product Backlog. Luego se mueven al Sprint Backlog y se dividen en tareas para completar. Las tareas movidas al Sprint Backlog se describen en lenguaje técnico, que es el más útil para los desarrolladores.

El tamaño de la tarea es una métrica importante desde el punto de vista del equipo de desarrollo. Su correcta estimación se vuelve especialmente crítica cuando se seleccionan User Stories desde Product Backlog hasta Sprint Backlog.

El equipo de desarrollo aprende con el tiempo a estimar correctamente el tiempo y el esfuerzo necesarios para completar una historia de usuario específica. Esto se expresa en días, horas-hombre o Puntos de historia y proporciona una estimación de un valor denominado Velocidad del equipo.

Resumen

El Product Backlog es una lista de tareas que se mejora continuamente y que conducen al objetivo del producto. El contenido del Product Backlog generalmente se expresa en forma de User Stories. Y cuanto más corto sea el tiempo restante para completar una tarea, el:

• La descripción del trabajo es más detallada.
• El alcance de la tarea es más pequeño.
• El alcance de la tarea está mejor definido

El Equipo Scrum se encarga de las tareas. El Product Owner gestiona y modifica el Product Backlog.

Si le gusta nuestro contenido, únase a nuestra comunidad de abejas ocupadas en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autora: Carolina Becker

Como Project Manager, Caroline es experta en encontrar nuevos métodos para diseñar los mejores flujos de trabajo y optimizar procesos. Sus habilidades organizativas y su capacidad para trabajar bajo la presión del tiempo la convierten en la mejor persona para convertir proyectos complicados en realidad.

Ver todas las publicaciones

Guía Scrum:

1. Glosario de términos básicos, roles y nociones
2. ¿Qué es Scrum?
3. valores de scrum
4. ¿Cómo implementar Scrum en tu empresa?
5. Equipo Scrum: ¿qué es y cómo funciona?
6. ¿Quién es un propietario del producto?
7. Los errores más comunes del Product Owner
8. ¿Quién es el Scrum Master?
9. Características de un buen Scrum Master
10. Los errores más comunes de Scrum Master
11. ¿Qué estadísticas y métricas debe rastrear el Scrum Master?
12. Cooperación entre el propietario del producto y Scrum Master
13. Equipo de desarrollo en Scrum
14. Los errores más comunes de los Desarrolladores
15. artefactos de scrum
16. Escalamiento Scrum
17. Pila de Sprint
18. ¿Qué es la cartera de productos?
19. ¿Qué son las historias de usuario?
20. Creando la mejor historia de usuario con INVEST
21. Los errores más comunes de las historias de usuario
22. Criterios de aceptación de historias de usuario
23. Estimación y puntos de historia en Scrum
24. Planificación de póquer
25. Juego de estimación en equipo
26. Definición de incremento
27. Eventos de scrum
28. ¿Qué es Sprint en Scrum?
29. Compromisos del equipo Scrum: objetivo del producto, objetivo del Sprint y definición de finalización
30. ¿Qué es un gráfico Burndown?
31. ¿Cómo crear e interpretar un gráfico de evolución?
32. Ventajas y desventajas del Burndown Chart
33. Tableros Kanban en Scrum y Scrumban
34. Velocidad en Scrum - Velocidad del Equipo de Desarrollo
35. Scrum diario
36. Planificación de Sprint
37. Revisión de Sprint
38. ¿Qué es una retrospectiva de Sprint?
39. Errores comunes durante una Retrospectiva de Sprint
40. Nutrición de la cartera de productos