Refinamiento de la lista de requisitos y cambios en el proyecto – Product Backlog Refinement

En las reuniones de planificación de entregas y durante el transcurso de una iteración (en el Product Backlog Refinement o Grooming), el cliente / Product Owner va trabajando en la lista de objetivos/requisitos priorizada del producto o proyecto, añadiendo requisitos, modificándolos, eliminándolos, repriorizándolos (cambiando el contenido de iteraciones, definiendo un calendario de entregas que se ajuste mejor a sus nuevas necesidades) [1] y detallando los requisitos conforme se acerca el momento de su desarrollo. Para poder hacer esta repriorización con toda la información necesaria, el equipo proporciona la estimación de los nuevos ítems y el impacto de los cambios que se necesita realizar. 

Para esta labor se utiliza entre un 10% y un 15% del tiempo del equipo y tiene lugar unos días antes de la finalización de la iteración, por si tras esas conversaciones es necesario investigar más en algún aspecto, de modo que la «gasolina» para la siguiente iteración esté preparada cuando se inicie.

Los cambios en la lista de requisitos pueden ser debidos a:
  • Modificaciones que el cliente solicita tras la demostración que el equipo realiza al final de cada iteración sobre los resultados obtenidos, ahora que el cliente entiende mejor el producto o proyecto.
  • Cambios en el contexto del proyecto (sacar al mercado un producto antes que su competidor, hacer frente a urgencias o nuevas peticiones de clientes, etc).
  • Nuevos requisitos o tareas como resultado de nuevos riesgos en el proyecto.
  • Etc.

pmpg1001

Para realizar esta tarea, el cliente colabora con el equipo:
  • Para cada nuevo objetivo/requisito, conjuntamente se hace una identificación inicial de sus condiciones de satisfacción (que se detallarán en la reunión de planificación de la iteración).
  • El cliente obtiene del equipo la re-estimación de costes de desarrollo para completar los objetivos/requisitos siguientes, según la definición de hecho. El equipo ajusta el factor de complejidad, el coste para completar los requisitos y su velocidad de desarrollo en función de la experiencia adquirida hasta ese momento en el proyecto.
  • El cliente re-prioriza la lista de objetivos/requisitos en función de estas nuevas estimaciones.
Hay que notar que el equipo sigue trabajando con los objetivos/requisitos de la iteración en curso, (que de hecho eran los más prioritarios al iniciar la iteración). No es posible cambiar los requisitos que se desarrollan durante la iteración. En la reunión de planificación de la iteración el cliente presentará la nueva lista de requisitos para que sea desarrollada.
 
Beneficios
De manera sistemática, iteración a iteración, se obtienen los siguientes beneficios:
  • El cliente puede tomar decisiones con tiempo respecto al progreso del proyecto y posibles desviaciones:
    • Replanificar el proyecto para obtener un nuevo calendario de entregas que cumpla con sus necesidades actuales.
    • Incorporar nuevos recursos.
    • Cancelar el proyecto con los requisitos completados hasta el momento plenamente operativos, si el beneficio pendiente de obtener es menor que el coste de desarrollo [2].
  • El plan de proyecto se actualiza con la velocidad de desarrollo del equipo, se evitan sorpresas de última hora.

Artículos relacionados

[1] Para permitir esta acción al cliente, ver como ejemplo la cláusula «Cambios de requisitos» en el artículo Un contrato ágil para Scrum.

[2] Para permitir esta acción al cliente, ver como ejemplo la cláusula «Finalización anticipada del contrato» en el artículo Un contrato ágil para Scrum.