Guía Scrum | 40. Nutrición de la acumulación de productos

La crianza del Product Backlog es una de las tareas principales de un Product Owner. El proceso de crianza incluye formular, detallar y agregar nuevas historias de usuario a la cartera de productos. Sin embargo, la más importante de las tareas de crianza es asegurarse de que las entradas colocadas en el Backlog estén en el orden correcto, es decir, sean priorizadas.

Nutrición de la cartera de productos: tabla de contenido:

1. Introducción
2. Propósito de la crianza de la cartera de productos
3. Errores en el mantenimiento de Product Backlog
4. Mantenimiento de la cartera de pedidos frente a las métricas utilizadas en Scrum
5. Resumen

Introducción

Product Backlog es uno de los artefactos de Scrum. Contiene una lista priorizada del trabajo necesario para crear un Producto. En otras palabras, es una lista de User Stories necesarias para lograr el Product Goal. Puede encontrar una descripción detallada de lo que son las historias de usuario en este artículo. Y aquí están los detalles sobre las características y cómo mantener el Product Backlog.

La crianza de la cartera de productos también se conoce con los siguientes nombres:

• Priorización de la cartera de pedidos,
• Refinamiento de la cartera de pedidos,
• Escalamiento de la cartera de pedidos.

Propósito de la crianza de la cartera de productos

El propietario del producto gestiona la cartera de productos. Las habilidades clave incluyen la priorización de tareas a medida que se acerca la fecha de vencimiento. Esto se debe a que el objetivo de nutrir la cartera de productos es asegurarse de que las funcionalidades del producto tengan el mayor valor comercial, es decir, aquellas más esenciales desde el punto de vista del cliente estén en la parte superior de la lista de tareas pendientes. Y su descripción es clara y detallada para que su implementación pueda comenzar en el próximo Sprint.

El Product Backlog puede actualizarse diariamente si es necesario. El propietario del producto puede agregar nuevas historias de usuario a la cartera de productos después de hablar con las partes interesadas y el equipo de desarrollo, o al sacar conclusiones y reformular las historias de usuarios ya escritas en la cartera de productos.

La actualización obligatoria del Backlog es una de las tareas realizadas durante Sprint Review. Describimos ese proceso en detalle en este artículo. Por lo general, durante esta reunión, el Equipo Scrum analiza no solo las tareas a completar en el próximo Sprint. También especifica preliminarmente las Historias de Usuario y su implementación en los próximos dos o tres Sprints. Esta forma de hacer las cosas permite que el Equipo Scrum y sus actividades tengan una visión más amplia de la dirección a largo plazo. Permite pensar las tareas que se están realizando actualmente desde la perspectiva de su desarrollo en Sprints posteriores.

Errores en el mantenimiento de Product Backlog

Uno de los problemas más comunes con respecto a la crianza del Product Backlog es permitir que se expanda sin control. Esto se debe a que, mientras se trabaja en el Producto, aparecen espontáneamente varias funcionalidades y tareas adicionales propuestas tanto por los Stakeholders como por los miembros del Scrum Team. Por lo tanto, limitar el crecimiento del alcance del Product Backlog (scope creep) es una de las tareas más importantes que realiza el Product Owner. Los errores más comunes que cometen los Product Owners son:

1. Desviarse del objetivo del producto : agregar demasiadas ideas a la cartera de productos más allá del objetivo básico del producto no es una buena práctica, ya que reduce en gran medida su legibilidad. Funciona mejor recopilar ideas para funciones adicionales en un documento separado.
2. Duplicación de contenido : ingresar ideas repetidas o muy similares de diferentes partes interesadas en el Backlog: antes de agregar otra entrada al Backlog, el propietario del producto debe asegurarse de que la nueva entrada no duplique ninguna de las existentes.
3. Falta de una perspectiva más amplia : debe ordenar las entradas de la cartera de productos de acuerdo con su valor con respecto al objetivo del producto. Aún así, tenga en cuenta que la priorización debe tener en cuenta los próximos Sprints para que las tareas realizadas en un Sprint determinado estén perfectamente vinculadas tanto al Sprint anterior como al Sprint inmediatamente posterior.

No se pueden evitar errores de este tipo. Sin embargo, el conocimiento de su ocurrencia puede hacer que el propietario del producto sea más cauteloso al agregar nuevas historias de usuario a la cartera de productos para lograr el equilibrio adecuado. Esto se debe a que también es un error cortar demasiado el Backlog y eliminar las entradas que contienen tareas similares que difieren. Por ejemplo, describir funcionalidades de Productos similares que difieren significativamente en la aplicación.

Mantenimiento de la cartera de pedidos frente a las métricas utilizadas en Scrum

El Product Backlog contiene una descripción del trabajo restante a lo largo del proyecto. Sin embargo, solo un Backlog actualizado y alimentado regularmente puede estimar con precisión la relación entre la cantidad de trabajo completado y el total. Para representar la cantidad de trabajo completado, debe aplicar el Burndown Chart, sobre el que escribimos en este artículo.

Otra métrica popular para describir el trabajo del Equipo Scrum es la Velocidad. Puede medirlo comparando el número de entradas de Product Backlog convertidas en Incremento durante un solo Sprint. Describimos Velocity con más detalle en este artículo.

Resumen

El Propietario del Producto realiza la Nutrición del Backlog del Producto. Cuando el Product Backlog está bien mantenido, el Scrum Team tiene una visión clara del trabajo que queda. También puede obtener una perspectiva más amplia y prospectiva de cómo se ve el camino hacia el objetivo del producto. Esta es la razón por la que el propietario del producto debe asegurarse de que las historias de usuario incluidas en la cartera de pedidos del producto estén en orden de prioridad para completarse. Y también que las tareas a completar en los próximos Sprints estén descritas con todo lujo de detalles.

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