Lista de productos pendientes
El Product Backlog es una lista priorizada de todo lo que podría incluirse en un producto. En Product Owner crea, mantiene y reordena periódicamente el Product Backlog para alinearlo con el Objetivo del producto. El Product Owner utiliza la cartera de productos pendientes para adaptarse a los nuevos requisitos, a las opiniones de los clientes y a los cambios del mercado.
Tiempo estimado para este curso: 5 minutos
Audiencia: Principiante
Requisitos previos sugeridos: Scrum Marco, Scrum Fundamentos
Una vez finalizado:
- Entender quién es responsable del Product Backlog
- Cómo se utiliza el Product Backlog para crear el Sprint Backlog
- Sepa cómo la equipo contribuye al Product Backlog
- Cualificarse para el PMI PDUs. Véase PREGUNTAS FRECUENTES para más detalles
Visión general de la cartera de productos:
El Product Backlog contiene todo el trabajo que hay que hacer para conseguir el Objetivo del producto. El retraso se compone de Elementos pendientes del producto (PBI). Los PBI pueden ser cualquier cosa, desde requisitos de mercado hasta casos de uso o especificaciones. Sin embargo, la mejor práctica es Historias de usuarios o historias de trabajo.
Los PBI de la parte superior de la cartera de productos deben ser refinados e inmediatamente procesables. Los elementos situados más abajo necesitan menos definición y pueden reflejar ideas más amplias. A medida que se acerquen a la parte superior del Backlog del Producto, estos elementos más grandes deberán dividirse en partes más pequeñas.
Compromiso: Objetivo de producto
El objetivo del producto describe un estado futuro del producto que puede servir de meta para la planificación del equipo Scrum. El Objetivo de Producto se encuentra en el Backlog de Producto. El resto del Backlog del Producto surge para definir "qué" cumplirá el Objetivo del Producto. Un producto es un vehículo para aportar valor. Tiene un límite claro, partes interesadas conocidas, usuarios o clientes bien definidos. Un producto puede ser un servicio, un producto físico o algo más abstracto. La meta del producto es el objetivo a largo plazo del equipo Scrum. Deben cumplir (o abandonar) un objetivo antes de abordar el siguiente.
Ver y descargar las diapositivas
[slideshow_deploy id='4336']
Más información sobre Product Backlog
La cartera de productos se perfecciona constantemente para reflejar cualquier cosa, desde los cambios que desea el cliente, los nuevos conocimientos o incluso las maniobras tácticas de los competidores. El sitio Equipo calcula el esfuerzo que requerirá cada elemento de la cartera de productos. El Product Owner calcula el Valor empresarial. Utilizan ambas estimaciones para decidir la priorización del backlog. El simple hecho de tener una lista ordenada de todo lo que hay que hacer mejorará notablemente el rendimiento del equipo. El equipo también debe trabajar con el Product Owner para asegurarse de que las historias reflejan con precisión el trabajo que hay que hacer. Esto ayudará al equipo a centrarse y a comprender con precisión lo que hay que hacer a continuación (véanse las diapositivas).
El Product Backlog es un documento vivo. En cualquier momento es la lista definitiva de todo lo que podría incluirse en el proyecto. Sólo hay un Product Backlog y el Product Owner es la única persona responsable de él. Esto es válido para varios equipos e incluso para una cartera de productos. (Véase Scrum a escala.)
El Product Owner debe tener los conocimientos y la autoridad necesarios para crecer y ayudar a ejecutar el proyecto a lo largo de su vida útil. El Product Owner decide cuándo se ha aportado suficiente valor para enviar el producto. Siempre se pueden añadir más funciones al proyecto. El Product Owner debe decidir si el valor empresarial de esas características justifica el esfuerzo. Una buena priorización del Product Backlog generará al menos 20% más valor de negocio y afectará directamente a los ingresos. Las empresas deben contratar a los mejores Product Owner que puedan encontrar y dedicarlos al Equipo a tiempo completo. (Para una explicación más detallada de esta investigación, véase "Software en cifras: Desarrollo de bajo riesgo y alto rendimiento" por Mark Denne y Jane Cleland-Huang).