Mantenimiento del backlog

Puede utilizar el backlog de tipo de caso (un resultado de la fase de descubrimiento (discover) ) como punto de partida para su backlog del proyecto. Esta ya contiene documentación para varios de los elementos que se convierten en épica y users stories.  

Como alternativa, los resultados de las sesiones de estrategia de diseño, como un sprint de diseño, son una rica fuente de ideas innovadoras. Los resultados tanto del backlog del tipo de caso como de las sesiones de diseño forman las entradas necesarias para llenar el backlog del proyecto durante la fase de preparación (prepare).

Durante la fase de preparación, el equipo del proyecto (con representación del área de negocio y de TI) trabaja en colaboración mutua para agregar detalles al backlog para tipos de caso, a fin de crear y documentar borradores de tipos de caso de alto nivel con herramientas de Pega.  Este esfuerzo colaborativo identifica las etapas y los pasos clave para el tipo de caso, además de asociar aspectos detallados de cada caso, como interfaces y Personas con el tipo de caso. Este detalle adicional hace que el equipo se concentre en la funcionalidad necesaria para entregar resultados de negocio y brinda una base para priorizar el trabajo.

La siguiente imagen muestra cómo la información asentada en el backlog para tipos de caso y los resultados de un sprint de diseño sirven para completar el backlog con borradores de épica y user stories.

La clave para crear su backlog es comprender que este puede cambiar en el tiempo. No se espera que un primer borrador incluya detalles en un 100 %. El equipo refina el backlog a medida que reúne más información y elabora las user stories en el tiempo. El equipo reúne datos del Product Owner, los Business Architects (BA), el Lead System Architect (LSA) y los evaluadores. Crear su backlog requiere una diversa variedad de puntos de vista para comprender lo que es importante, qué priorizar y cuándo entregar cada user story.

Los backlogs evolucionan y cambian de manera continua a lo largo del tiempo. Si bien el Product Owner es responsable de priorizar el backlog, usted, como Business Architect de Pega, se reúne periódicamente con el PO para actualizarlo y asesorarlo sobre el estado actual del proyecto.

Junto con la orden de compra, se asegura de que el backlog incluya user stories actualizadas y se priorice de acuerdo con el valor de negocio que ofrecen las user stories. Las user stories nuevas se pueden priorizar sobre otras, y algunas se pueden reemplazar. Es posible que user stories existentes ya no sean necesarias, y se podrán quitar. La gestión y priorización del backlog es una actividad permanente que continúa durante todas las fases del proyecto. 

El Product Owner es el propietario del backlog. El PO crea el backlog, lo mantiene actualizado y prioriza las historias de usuarios. En el comienzo del proyecto, el Product Owner y el equipo del proyecto deben acordar el enfoque de gestión del proyecto y los objetos de trabajo de la aplicación.

Al tomar decisiones de priorización, el Product Owner tiene una amplia variedad de historias de usuarios. Algunas historias son elaboradas, se comprenden correctamente y están listas para el desarrollo. Otras aún se encuentran en etapas tempranas del ciclo de vida de la historia del usuario. Esta variedad implica que el Product Owner debe considerar tanto las metas de corto plazo para la planificación del sprint como las metas de largo plazo para la planificación de la elaboración cuando se trata de priorizar historias en el backlog.  

Compruebe sus conocimientos con la siguiente actividad: