Lista de objetivos / requisitos priorizada (Product Backlog)

La lista de objetivos/requisitos priorizada representa la visión y expectativas del cliente respecto a los objetivos y entregas del producto o proyecto. El cliente es el responsable de crear y gestionar la lista (con la ayuda del Facilitador y del equipo, quien proporciona el coste estimado de completar cada requisito). Dado que reflejar las expectativas del cliente, esta lista permite involucrarle en la dirección de los resultados del producto o proyecto.

  • Contiene los objetivos/requisitos de alto nivel del producto o proyecto, que se suelen expresar en forma de historias de usuario. Para cada objetivo/requisito se indica el valor que aporta al cliente y el coste estimado de completarlo. La lista está priorizada balanceando el valor que cada requisito aporta al negocio frente al coste estimado que tiene su desarrollo, es decir, basándose en el Retorno de la Inversión (ROI).
  • En la lista se indican las posibles iteraciones y las entregas (releases) esperadas por el cliente (los puntos en los cuales desea que se le entreguen los objetivos/requisitos completados hasta ese momento), en función de la velocidad de desarrollo del (los) equipo(s) que trabajará(n) en el proyecto. Es conveniente que el contenido de cada iteración tenga una coherencia, de manera que se reduzca el esfuerzo de completar todos sus objetivos.
  • La lista también tiene que considerar los riesgos del proyecto e incluir los requisitos o tareas necesarios para mitigarlos.
 
Antes de iniciar la primera iteración, el cliente debe tener definida la meta del producto o proyecto y la lista de requisitos creada. No es necesario que la lista sea completa ni que todos los requisitos estén detallados al mismo nivel. Basta con que estén identificados y con suficiente detalle los requisitos más prioritarios con los que el equipo empezará a trabajar. Los requisitos de iteraciones futuras pueden ser mucho más amplios y generales. La incertidumbre y complejidad propia de un proyecto hacen conveniente no detallar todos los requisitos hasta que su desarrollo esté próximo. De esta manera, el esfuerzo de recoger, detallar y desarrollar el resto de requisitos (menos prioritarios) está repartido en el período de ejecución del proyecto. En el caso del desarrollo de un producto, la lista va evolucionando durante toda la vida del producto (los requisitos "emergen"). En el caso de un proyecto, conforme éste avance irán apareciendo los requisitos menos prioritarios que falten. Esto produce varias ventajas:
  • Se evita caer en parálisis de análisis al inicio del proyecto, de manera que se puede iniciar antes el desarrollo y el cliente puede empezar a obtener resultados útiles.
  • Se evita analizar en detalle requisitos no prioritarios que podrían cambiar durante el transcurso del proyecto, dado que el cliente conocerá mejor cuál ha de ser el resultado a conseguir, o bien por que podrían ser reemplazados por otros.
  • Puede llegar a un punto del proyecto en que no valga la pena analizar ni desarrollar los requisitos restantes, dado el poco retorno de inversión (ROI) que tienen.

 

Definición de completado (Definition of Done)

El cliente y el equipo tienen que acordar la "definición de completado” de los objetivos / requisitos en el proyecto:
  • Debe asegurar que el incremento de producto es potencialmente entregable al cliente al finalizar cada iteración, que no hay tareas pendientes que puedan impedir utilizar los resultados del proyecto lo antes posible. De este modo, el cliente podrá tomar decisiones correctas cuando al final de cada iteración el equipo le haga una demostración de los requisitos completados: cambiar las prioridades en función de la velocidad de desarrollo, solicitar una entrega del producto desarrollado hasta ese momento, etc.
  • Debe incluir lo necesario para considerar de manera clara que el cliente obtendrá lo que necesita según sus criterios de entregables y de calidad (producto construido, probado, documentado, refactorizado para conseguir calidad interna/mantenibilidad, etc.).
    • Además de esta definición de completado, a cada objetivo hay que asociarle sus condiciones de satisfacción, preferiblemente en forma de casos de prueba de aceptación, en el momento de crear la lista de requisitos priorizada (Product Backlog).
    • Notar que la definición de completado también sirve como base para identificar las tareas necesarias para conseguir cada objetivo/requisito, en la reunión de planificación de la iteración (Sprint planning). Para cada objetivo se crearán más tareas que la definición de completado (o menos) y con más significado. Por ejemplo, respecto a que el objetivo tiene que estar “construido”, pueden aparecer varias tareas, del estilo “construir el componente X”, “modificar la pantalla Y”, “modificar la BBDD”, “preparar el script de carga”, etc.

 

Iteración de entrega (release sprint)

Cuando el cliente solicita una entrega de los objetivos/requisitos completados hasta ese momento, el equipo puede necesitar añadir una iteración de entrega, más corta que las iteraciones habituales, donde realizar alguna tarea que no ha sido necesaria o posible hasta el momento de la entrega final y acabar de corregir defectos detectados en la última demostración.
 

Uso de la lista

  • Para medir la velocidad de desarrollo del equipo, ver una progresión constante y extrapolar la fecha de las entregas, es conveniente seguir las siguientes recomendaciones:
    • Los requisitos deben tener un esfuerzo semejante para ser completados. 
    • La estimación de un requisito no debe ser superior a 10 días (si las iteraciones son de 20 días laborables). 
  • Cada requisito tiene asociado un factor de complejidad, que permite ajustar su coste estimado en función de la incertidumbre de la complejidad de su desarrollo en el momento de introducirlo en la lista. Este factor de coste se irá ajustando conforme las iteraciones avancen y el equipo conozca mejor el producto o proyecto, su contexto y su velocidad de desarrollo con las herramientas y tecnologías que utiliza.
  • Si un requisito depende de otro, se coloca en algún punto por debajo del que depende.
  • Si un requisito no se finaliza en una iteración, se le vuelve a poner en alguna de las siguientes iteraciones, indicando el coste pendiente de desarrollo.
  • El "origen" permite saber quién podría participar en la definición de un objetivo/requisito y sería conveniente que estuviese presente en el momento de su demostración.

El progreso del proyecto y su velocidad con respecto a requisitos completados se muestra en un gráfico de trabajo pendiente (Burndown chart).

 

Artículos relacionados