Tras haber ido comentando sobre los roles y las reuniones de Scrum, como se puede ver en el artículo anterior, continúo con las definiciones y artefactos que se usan a lo largo de todo el ciclo de Scrum. En concreto, hoy trataré el Product Backlog. Recuerdo que una lectura fundamental para el que se quiera iniciar en este marco de gestión es la guía de Scrum, que he tomado como base para estructurar la presente serie de artículos.

La lista de producto (product Backlog) en Scrum

Viene a representar la hoja de ruta del producto, siendo el Product Owner el principal responsable de la misma. En concreto es fundamental que esté convenientemente priorizada según el valor aportado al negocio (posiblemente ponderado conforme a criterios de coste o esfuerzo), ya que en cada sprint se eligen preferentemente los elementos de mayor prioridad para poner el foco en su construcción.

La lista de producto está en continua evolución, hasta que el producto deje de tener sentido de negocio. Así, la visión tradicional de un proyecto cuyas condiciones de finalización son bien conocidas desde el inicio se transforma en una especie de proyecto continuo donde en cada sprint se va decidiendo lo que hacer en el futuro.

Aspectos críticos de la lista de producto

Las métricas

Ya podemos imaginar que las métricas típicas para medir el éxito del proyecto (desviaciones entre lo previsto y lo real a lo largo del proyecto completo), no tienen demasiado sentido en un marco tan cambiante y de un futuro muy difuso a largo plazo. Tampoco es sencillo acordar contratos a precio cerrado y fecha de entrega pactada, ya que necesariamente el proveedor tiene que limitar el número de cambios en ese marco. Esto no quiere decir que renunciemos a ciertas medidas, como la de la velocidad del sprint, y sobre todo a la del valor de lo entregado y la consecución del objetivo del sprint, pero el éxito de scrum requiere una gestión muy ligera.

Hay que tener muy claro que Scrum no está especialmente pensado para el ahorro de costes de producción, sino para que los costes (asumidos a lo largo del ciclo de vida del producto) sean convenientemente invertidos en desarrollar un producto valioso. Tampoco es buena idea mantener un sistema de control de tiempos de técnicos y tareas individuales, aunque solo sea porque amenaza el trabajo en equipo  con una serie de objetivos comunes.

Lista única

Otro aspecto crítico es que la lista debe ser única para un producto dado, incluso si participa más de un equipo de scrum. De esta manera resulta ser una verdadera hoja de ruta, en vez de un conjunto de peticiones de usuarios que realizan cada uno de forma independiente. Así el rol del product owner es también el de coordinador de usuarios y otros interesados, elaborando una lista representativa, coherente y priorizada, de las características que debe tener el producto.

Desglose

Lo habitual es que los elementos más prioritarios aparezcan más desglosados, y por ello con estimaciones (esfuerzo, riesgos, complejidad) más fiables realizadas por el equipo de desarrollo. Recuerdo que esto se va haciendo en las reuniones de refinamiento de la lista de producto, y también en las de la planificación del inicio del sprint, aunque realmente se puede hacer en cualquier momento en que sea necesario.

El desglose tiene que llegar al menos hasta el nivel en el que los elementos pueden implementarse (terminarse) en un único sprint, de otra manera nunca podrían ser elegidos. Se deduce que es mala práctica conformarse con elementos menos desglosados cuando hay que abordar la reunión de planificación del sprint. También al flexibilizar scrum para trabajar con elementos donde se sabe que no se van a poder completar en un único sprint, algo que precisamente menciono por lo común que resulta.

Aplicación en proyectos de Big Data & Analytics

Como lecciones prácticas, quiero aclarar que la lista de producto no es solo una lista de funcionalidades para negocio, aunque sí que la mayor parte del esfuerzo debería recaer sobre las mismas. Pero también tienen cabida tareas técnicas como la reestructuración del código, la formación de equipo, la investigación de nuevas técnicas, la mejora del tiempo de respuesta, etc. Teniendo potestad el equipo técnico para incluir elementos de este tipo dentro de la lista.

Esto es especialmente relevante en el contexto de los proyectos de analítica, Big Data y BI. Debemos contar con los consabidos problemas de calidad de datos. Estos exigen tareas específicas para tratarlos, sin que a veces se pueda poner algo concreto a disposición de los usuarios en un entorno de producción. En cambio, sí que podemos pensar en prototipos, ciertas entidades mejor definidas, etc., donde los usuarios tienen una responsabilidad continua respecto a la validación y las pruebas.

También necesitamos reservar tiempo para la investigación de nuevas tecnologías, porque quizás tengamos que probar varias de ellas, realizar diferentes modelos estadísticos antes de dar con uno suficientemente bueno, etc.

Conclusión

En resumen, no siempre se puede entregar una novedad significativa del producto en cada sprint en términos estrictamente funcionales, y por ello hay que saber buscar un equilibrio entre las entregas frecuentes y los aspectos que tienen más que ver con la calidad técnica.

A veces se considera un sprint especial cada cierto tiempo para abordar tareas que no están estrictamente asociadas a la funcionalidad, incluyendo el sprint 0 del que ya comenté en otro artículo. Pero no conviene tomar decisiones de gestión simplemente para reportar un mejor dato de velocidad. El rey es el producto, y esto incluye necesariamente tareas orientadas a asegurar la calidad del mismo, que podemos considerar prácticamente continuas, aunque puedan parecer un hándicap para la velocidad.

Me viene a la mente el interesante concepto de “deuda técnica”. Sin ser muy riguroso en la definición, diré que entregar software fabricado de manera muy rápida pero sin preocuparse de su calidad, es como haber recibido un préstamo, que nos ha permitido cumplir con un compromiso. Pero luego toca devolver los intereses, pensemos en posibles incidencias que hay que reparar de manera urgente, mantenimientos más costosos, etc. Y si los intereses empiezan a ser inabordables, tendremos que devolver todo el capital, o bien rehacer el código desde cero.

José Julio López, Business Intelligence, Data Science, IT Project Manager. SCRUM Master, PMP y antiguo alumno del máster de Big Data & Analytics de datahack.

MÁSTER EXPERTO BIG DATA ANALYTICS

Gracias al Master en Big Data Analytics 100% Online tendrás amplios conocimientos sobre las herramientas y técnicas analíticas necesarias para la modelización de los principales retos de negocio, con el fin de mejorar la toma de decisiones a través de los datos y el conocimiento.