Product Backlog: ejemplo de cómo elaborarlo
Anteriormente hemos hablado de Scrum, de sus características como metodología de planificación y de los beneficios que supone para proyectos complejos, con numerosas miembros o actividades simultáneas. No obstante, aún no hemos reparado en una de sus herramientas indispensables. Se trata del Product Backlog o lista de objetivos, 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. Veamos cuáles son los elementos que le caracterizan:
- 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.
Manos a la lista: cómo elaborar un Product Backlog
El Product Backlog siempre dependerá de la naturaleza de cada proyecto y del número de necesidades que se generen a lo largo de su ejecución. Lo que en un caso se aplica satisfactoriamente en otro 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.
