¿Por qué invertir en el Product Backlog?

Estemos en un contexto Ágil o no, es muy evidente que para que un proyecto tenga éxito debemos tener una buena visión del sistema o producto que vamos a desarrollar, a través de la definición adecuada de la necesidad a la que responde.

Por lo tanto, en Scrum no existe un proyecto exitoso sin un Product Backlog bien construido e inteligentemente priorizado. Evidentemente, para esto el Product Owner juega un rol fundamental, por su conocimiento del negocio y/o del mercado, así como por su capacidad de separar, ordenar y transcribir eficazmente lo que esperan los usuarios del software.

Ahí donde teníamos la costumbre como "Cliente" de escribir las especificaciones funcionales detalladas que expresaban las necesidades, nos tenemos que familiarizar con un nuevo método. Esta familiarización implica un tiempo de aprendizaje y se debe compartir por todo el conjunto de las partes integrantes del proyecto, lo que significará formación, asimilación y puesta en marcha de nuevas técnicas.

Por lo tanto en este capítulo vamos a recorrer los conceptos y métodos que permiten construir, ordenar, afinar y gestionar de manera cotidiana el Product Backlog.

La pieza básica del Product Backlog: la User Story

Por increíble que parezca, Scrum no atiende a un formato o contenido concreto del Backlog. Sin embargo, se impone un formalismo y este se encuentra casi de manera sistemática en todos los proyectos Scrum: se trata de la noción de User Story, que se toma prestada de XP.

Una User Story es una descripción sencilla y comprensible de un elemento de funcionalidad con valor "de negocio" para el sistema. Por tanto, se debe expresar correctamente desde el punto de vista del usuario. Se guía por las respuestas a estas tres preguntas:

¿Quién realiza la petición o quién se beneficia de la petición? (rol usuario)
¿Cuál es la petición? (la necesidad)
¿Cuál es el valor para el negocio que se deriva de la realización de esta necesidad?

A continuación se enumeran algunos ejemplos (veremos más adelante cómo redactar correctamente las User Stories):

"Deseo que el IVA se calcule automáticamente en las facturas".

"Deseo poder eliminar los clientes que hayan realizado pedidos hace más de un año".

Además, también se usa la noción de Epic Story. Se puede considerar una Epic como una "macro User Story", es decir, engloba en su definición un sub-conjunto de User Stories.

Por ejemplo, en relación con las User Stories descritas...

¿Cómo redactar las User Stories y Epics?

1. Regla de las 3C

Para guiar la redacción de las User Stories, Ron Jeffries propone un principio muy sencillo que es necesario tener en cuenta. Se trata de la regla de las 3C:

Tarjeta (Card, en inglés)	La Story se escribe en una tarjeta de tamaño muy reducido. Estas fichas pueden contener notas (estimación, etc.).
Conversación	Los detalles de la Story se expresarán durante las conversaciones con el Product Owner.
Confirmación	Se describen las pruebas de validación para la Story (servirán para validar que se ha realizado correctamente).

En la práctica, la Story se escribirá en una pequeña tarjeta de color colgada en un tablero (si recuerda, este principio se hereda de Kanban), bajo la siguiente forma:

Empezamos con un título.
Se añade una descripción resumida de la "tarea de usuario" y de sus objetivos.
Se pueden agregar todas las notas, dibujos o informaciones útiles. Por ejemplo: estimaciones, indicador de prioridad o valor de negocio.
De manera ideal se anotan los criterios de validación (por ejemplo en el reverso, si no hay espacio suficiente).

De una forma muy sencilla, resultará en algo parecido a lo que se muestra a continuación:

La tarjeta es un concepto de información compartida extremadamente resumida y eficaz, pero tan pronto como se añadan datos adicionales como consecuencia del análisis, preste atención con no sobrecargarla. Con demasiada rapidez, vemos cómo llega la necesidad de pasar por una herramienta más sofisticada (e informatizada) para gestionar la información: hablaremos de esto más adelante.

2. Redactar una buena User Story: el principio INVEST

Cuando se entra en el proceso de redacción, rápidamente nos podemos perder. En este caso hay otro principio muy útil que le puede guiar: se trata del principio INVEST.

Indica que una buena User Story debe ser:

Independiente del resto de historias de usuario (en la medida de lo posible).
Negociable: se debe poder discutir con el equipo encargado de la realización del producto, fundamentalmente durante la estimación.
Origen del Valor: debe tener valor para el cliente o el usuario.

Una User Story no describe los objetivos técnicos.

Estimable: se debe poder estimar por el equipo de realización...

Gestionar su Backlog en la práctica

Puede prever diferentes maneras para gestionar su Backlog de Producto.

La práctica básica es utilizar soportes puramente visuales, como los tableros con post-it. Claramente es un buen medio para hacer visible a todos los actores del proyecto el contenido del mismo.

Sin embargo, vemos rápidamente que es complicado (incluso imposible) gestionar toda la información asociada a las User Stories en este tipo de soporte (por ejemplo: especificaciones, descripción de las pruebas de validación, etc.).

Por consiguiente, tiene varias opciones.

La más sencilla consiste en materializar el Backlog de Producto en su tablero preferido. Como ejemplo, proporcionamos un modelo de archivo que hay que adaptar a sus necesidades, que le permitirá gestionar toda la información principal y seguir el progreso global del proyecto:

La siguiente etapa, que estaremos tentados de realizar lo antes posible, es utilizar un software de gestión de proyecto ágil (gratuito o de pago), diseñado para soportar Scrum: se dedica un capítulo a esto más adelante en este libro.

Conclusión

Ahora tiene entre manos todas las claves que le permiten construir y mantener el Backlog de Producto: si usted es Product Owner, esperamos que pueda pasar rápidamente a la práctica, para experimentar los métodos descritos. Los métodos de priorización le pueden parecer complicados en este estado, pero haga el esfuerzo de probarlos: multiplicará el valor añadido de su trabajo.

Pero haber definido el contenido del sistema que se debe realizar no basta para lanzarse directamente a su construcción: es necesario dominar e implementar los métodos correctos de estimación y planificación, que se describen en el siguiente capítulo.

Construir y priorizar el Product Backlog