Product Backlog · Lista de Objetivos o Requisitos Priorizados
Continuando con las metodologías ágiles, nos detenemos en un punto de suma importancia para la realización de alguna iteración: El Product Backlog. En español, se trata de la lista de productos requeridos por el Product Owner, es decir el dueño del producto.
¿Qué contiene un Product Backlog?
En resumidas palabras, todo. Así es, en el Product Backlog están detallados uno a uno los requerimientos del Product Owner y lo que podría ser necesario durante un Sprint. Ahora bien, el Product Backlog no es una lista que se hace y no admite cambios, todo lo contrario, es muy dinámica, porque es común que el entorno en el que será aplicado mute y por tanto deben hacerse adaptaciones. He aquí una lección de vida, ¡No temas el cambio!
¿Qué encontramos en un Product Backlog?
Esta respuesta es sencilla; encuentras especificaciones para el desarrollo, funciones del producto, correcciones y perfeccionamiento que deben hacerse sobre el producto. Básicamente en esta lista, encontramos procesos descritos, pasos a cumplir, valores y cálculos para cumplir el objetivo. Es posible que los tiempos de cada iteración puedan estar demarcados ahí en la lista de productos y las entregas estimadas por nuestro dueño.
Las historias de usuario son muy importantes:
En una lista de producto, las historias de usuarios son de suma importancia, porque los puntos que aparecen ahí marcados son descritos generalmente a manera de relato, es decir, un pequeño cuento en el que a través de la voz de un usuario se agrega el punto que se desea mejorar, cambiar, perfeccionar; algo así como esto, suponiendo que hablamos de la creación de e-commerce: “Cuando se agreguen nuevos productos de mi gusto a la tienda virtual, deseo que llegue una notificación a móvil”.
Es común que los primeros puntos que aparezcan en esa lista están mejor descritos que los últimos –típico- lo más escueto para lo último. Pero no hay problema, a medida que se van cumpliendo objetivos, estos pueden ir siendo mejor especificados. Recuerda que esto se trata de dinamismo, de no detenerse en nimiedades.
Existe otro punto importante y es que, una vez que el dueño del producto presenta cada una de las historias de usuario, es el Product Owner quien hace la jerarquía de trabajo, pudiendo tomar, como generalmente sucede, esas ideas más desarrollados para ampliar durante el siguiente sprint. Es usual que durante este paso se seleccionen al menos cinco puntos y pueden agregarse algunos más que guarden relación con los seleccionados. A partir de este momento inicia el Sprint Backlog, es recomendable ¡no confundirlos! En otra entrega hablaremos sobre quién es este personaje.
Es común que varios equipos Scrum trabajen sobre un mismo producto o requerimiento. En ese caso se utiliza un solo Product Backlog. ¿Cuándo es necesario someter a cambios esta lista? Cuando el Scrum encargado lo decida, por supuesto, es lógico, son ellos quienes más empapados están acerca del producto, son ellos quienes le desarrollan.
Cuando hablamos de cambio nos referimos a un refinement (refinamiento), en donde se le agregan detalles, se ordenan algunos elementos y puede que se hagan cálculos. Es aquí donde vuelve el más interesado en que todo vaya bien, nuestro Producto Owner, para colaborar con el equipo en los detalles que serán posteriormente incorporados a la lista de producto.
También es necesario tener en cuenta algunos riesgos en esta lista de consideraciones así como desarrollar ideas para minimizar sus efectos o evitarlos de manera total.
¿Por qué es importante hacerlo?
- Plantea una visualización previa de lo que desea el dueño del producto y cómo cumplirlo, antes de iniciar el Sprint.
- Ayuda a mantener orden y disciplina dentro del Scrum, además de respetar de cierta forma la priorización que pueda proponer el cliente.
- Promueve el perfeccionamiento del proyecto con la incorporación de distintas propuestas.
- Ordena el trabajo del Scrum durante el siguiente Sprint.
- El trabajo del equipo tiende a hacerse más llevadero.
Las expectativas del cliente son siempre una prioridad, así que es mejor no saltarse sus demandas; el éxito de toda metodología ágil se encuentra en cumplir con cabalidad los procesos.