Anteriormente hemos hablado de SCRUM y de sus características como metodología de planificación con numerosos beneficios para todo tipo de proyectos.

No obstante, el día de hoy hablaremos sobre una de sus herramientas indispensables. Se trata del Product Backlog o lista de objetivos, el cual es una especie de documento que forma parte de la etapa de planificación de cualquier proyecto. Pero ojo, no se trata sólo de una lista convencional en la que se enumeran de forma genérica los elementos que conforman un proyecto. Es mucho más que eso.

¿Qué es el Product Backlog?

Es una planificación estratégica que evoluciona a lo largo de toda la vida del producto/proyecto, debido a cambios de necesidades del cliente, feedback del mercado, aparición de nuevas ideas, dificultades tecnológicas, entre otros.

El orden de los ítems del Product Backlog viene determinado por el valor que aporta al cliente final respecto a riesgos y coste estimado de completarlo (ROI).

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 involucrarse en la dirección de los resultados del producto o proyecto.

Características del Product Backlog

  • Los objetivos/requisitos se expresan detalladamente. Se les asigna el valor que suponen y el coste estimado para su ejecución.
  • A la hora de priorizar objetivos, el criterio que se sigue es la relación entre el valor de cada tarea para el conjunto del proyecto y el coste que supone su puesta en marcha. Es decir, se analiza su inversión.
  • Del mismo modo, en la lista se expresan las iteraciones y los plazos para la ejecución de cada objetivo/requisito. Para ello, se debe tener en cuenta la capacidad productiva de los equipos involucrados en la ejecución.
  • En la misma lista se debe añadir una columna en la que se haga mención de los riesgos de cada iteración y algunas actividades para mitigarlos, evitarlos o, si es el caso, eliminarlos del todo.

El Product Backlog puede aplicarse de forma genérica o para iteraciones puntuales. En el segundo caso, conviene no elaborar la lista antes de que haya terminado la anterior iteración, pues es probable que algunos elementos se modifiquen.

Cómo elaborar un Product Backlog

La elaboración del Product Backlog siempre dependerá de la naturaleza del proyecto y del número de necesidades que se generen a lo largo del desarrollo del proyecto.

Lo que en ciertos casos se aplique satisfactoriamente, en otros casos puede ser un fallo rotundo. Lo que sí es cierto es que todas las listas de objetivos o requisitos deben tener un mínimo de elementos. Una buena forma de elaborarlas es a partir de los siguientes parámetros:

  • Elementos imprescindibles (Must have):

En este apartado se apuntan las tareas que son consustanciales al proyecto, es decir, que no pueden obviarse porque pondrían en riesgo la ejecución del mismo. Por lo general, se expresan como objetivos a gran escala.

  • Elementos importantes (Should have):

Son tareas o aspectos de mediana envergadura, pero que no alcanzan a determinar el curso de la ejecución de un proyecto. En muchos casos se derivan de los objetivos incluidos en la primera categoría.

  • Elementos interesantes (Could have):

Más que tareas o elementos específicos, son oportunidades que se podrían valorar para la puesta en marcha del proyecto. Muchas de ellas se expresan en condicional y siempre como alternativas a algo.

  • Elementos opcionales (Won´t have now but Would be later):

Finalmente, lo opcional es aquello que está a nuestro alcance, pero que no por ello resulta necesariamente importante para un proyecto. A diferencia de las tareas de la categoría anterior, en este caso hablamos de alternativas que pueden llevarse a cabo en cualquier momento, pero que sin embargo pueden esperar. Su ejecución no tiene gran influencia en el conjunto de actividades.

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.

Idealmente esta iteración de entrega no debería existir (o reducirse a tareas mínimas dentro de una iteración) si:

  • Se ha trabajado con una buena Definición de Hecho durante cada iteración del proyecto.
  • Se hacen entregas muy cortas cada poco tiempo, con lo que la cantidad de cosas a entregar, integrar y probar es pequeña.
  • Se está realizando un esfuerzo de automatización de estas tareas de pruebas, iteración y entrega durante todo el proyecto (con lo cual se gana en eficiencia y seguridad).

En InGenio Learning  ofrecemos un curso de scrum en Lima basado en una de esta metodología ágil, que es una de las más demandadas en el mercado actual, con este curso obtendrás las bases para certificarte como un SCRUM MASTER para aumentar tu empleabilidad y mejorar tu talento digital.