El Product Backlog es la única fuente de tareas realizadas por el equipo de Scrum. Es una lista de funcionalidades y mejoras del producto planificadas. Su forma es cambiante y no todas las tareas incluidas en el Product Backlog se completarán. Evoluciona durante las discusiones con los interesados. También se mejora constantemente. Esto significa que cuanto más cerca esté la fecha límite, más detallada se vuelve una tarea.
El 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 el trabajo en un producto se completa, su Backlog se convierte en una lista completa de las tareas realizadas por el equipo de Scrum para crear el producto. Sin embargo, no contiene soluciones técnicas detalladas.
El Product Backlog se crea durante las reuniones del Product Owner con los interesados. El Product Owner es el único propietario y la persona responsable de esta fuente de tareas.
El lenguaje empresarial caracteriza las entradas en el Product Backlog. En otras palabras, describen el valor del producto desde el punto de vista de los interesados.
Las descripciones de las tareas incluidas en la lista de tareas necesitan coherencia y claridad. Contienen funciones y mejoras del producto que generalmente se presentan en forma de historias de usuario, a las que dedicamos una entrada separada. Aquí solo mencionaremos que estas son descripciones de funcionalidades parciales del producto que responden a las preguntas sobre los siguientes temas:
El orden de las tareas incluidas en el Product Backlog cambia a medida que el producto se desarrolla. Mientras se trabaja en él, el equipo de Scrum da forma y mejora sus funcionalidades. Al encontrar obstáculos, las acciones implementadas permiten a todos pensar y definir futuras soluciones adecuadas, y estas también cambiarán de acuerdo con obstáculos imprevistos. Por lo tanto, no hay un orden claro y definido de acciones, todo es cambiante. La mejora del Product Backlog está destinada a su continuo actualización y preparación para las próximas tareas. Por esta razón, es continua.
Las tareas con una fecha límite lejana son típicamente grandes y genéricas. Su descripción no contiene detalles, sino solo un esbozo de la funcionalidad que debe realizarse. También es posible encontrar entre ellas tareas que nunca se completarán.
Las entradas en el Product Backlog pueden presentar soluciones alternativas. Y también las ideas del cliente que pueden volverse obsoletas, no rentables o por alguna otra razón nunca entrar en la fase de implementación. Por eso, 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 redefinir soluciones. A veces resulta que un cierto problema ya se ha resuelto al crear otra funcionalidad del 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 esbozo general de la 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ñas, conteniendo detalles de soluciones. Los detalles surgen durante el desarrollo del producto. Y gracias al conocimiento del estado actual del producto y las expectativas actuales de los interesados, 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.
Mientras trabaja en un producto, el Product Owner modifica y detalla el Product Backlog en cooperación con el equipo de desarrollo. Siguiendo las sugerencias del Product Owner, durante la planificación del Sprint, el equipo selecciona características para implementar del Product Backlog. Luego se trasladan al Sprint Backlog y se dividen en tareas a completar. Las tareas trasladadas 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 al seleccionar historias de usuario del Product Backlog al Sprint Backlog.
Con el tiempo, el equipo de desarrollo aprende a estimar correctamente el tiempo y el esfuerzo requeridos 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 llamado velocidad del equipo.
El Product Backlog es una lista de tareas en continua mejora que conduce al objetivo del producto. El contenido del Product Backlog se expresa generalmente en forma de historias de usuario. Y cuanto más corto sea el tiempo restante para completar una tarea,:
El equipo de Scrum se encarga de las tareas. El Product Owner gestiona y modifica el Product Backlog.
Si te gusta nuestro contenido, únete a nuestra comunidad de abejas trabajadoras en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Como Gerente de Proyectos, 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 presión de tiempo la convierten en la mejor persona para hacer realidad proyectos complicados.
¿Eres un freelancer que busca formas de promocionar su portafolio? Hoy en día, no solo…
La gestión financiera digital y la contabilidad en línea se han vuelto cada vez más…
Los estatutos del proyecto son el pan y la mantequilla de la gestión de proyectos.…
Las organizaciones de diversas industrias establecen relaciones con posibles empleados, proveedores y socios todos los…
Hay más que suficientes técnicas de gestión por ahí. Algunas parecen intrincadas, mientras que otras…
¿Sabes cómo empezar una ONG? ¿Has estado pensando en ello? ¿Eres consciente de lo que…