La trampa de las historias técnicas
Y ¿cómo sacar la pata de ella?
Es común que los equipos encuentren desafíos trabajando con historias de usuario como herramienta para especificar lo que tienen que hacer. Es entendible que a veces hay que desarrollar cosas que tienen, en apariencia, poco o nada que ver con interacciones de usuarios. En esos casos, los equipos suelen adoptar las historias técnicas, solucionar sus problemas y seguir trabajando con la nueva libertad que ellas les han dado. Pueden tomar decisiones rápidas sobre su trabajo, definir y dirigir sus esfuerzos a cosas que se consideran valiosas para el proyecto, reducir deuda técnica y otro sin fin de beneficios.
¿Dónde está la trampa?
Los equipos de desarrollo suelen ser quienes identifican las historias técnicas o al menos identifican necesidades meramente técnicas. Actualizar la arquitectura, mejorar un algoritmo o estructura de datos, etc. Como suele pasar, el lenguaje usado por el equipo de desarrollo es altamente técnico y junto a su ego, pueden tomar la decisión de no compartir ese trabajo pendiente con la Dueña de Producto. Y así se queda, una historia que describe un requerimiento no funcional o restricciones que el equipo va a trabajar sin contar con la Dueña del Producto.
En este escenario hipotético hay varias cosas que debemos resaltar. Y trataré de no ser muy extenso.
1. Hay que recordar que la Dueña del Producto es la única persona responsable de administrar el Backlog del Producto y que este artefacto es la lista de todo lo que sea necesario hacer para construir el producto. Entonces, si el producto necesita que se haga algo, sea funcional o no, debe estar en el Backlog del Producto y debe ser conocido por la Dueña del Producto para que pueda priorizar su desarrollo.
2. Aunque la Dueña del Producto puede delegar sus funciones de administración del Backlog del Producto en otras personas del Equipo Scrum, la responsabilidad sigue siendo suya y de nadie más. ¿Cómo podemos exigirle a la Dueña del Producto que maximice el valor del producto que resulta del trabajo del equipo de desarrollo, si hay cosas que el equipo va a trabajar sin que ella sepa ni sepa del valor que dan al producto?
3. Revisando con cuidado lo planteado en el escenario, es difícil de creer que un equipo se asigne, defina y desarrolle historias técnicas sin que se haya enterado su Dueña del Producto. Es de suponer que la empresa tiene una organización deficiente para la gestión del equipo Scrum. Debe haber alguien que promueve que haya una división de historias, que las mantiene ocultas a la Dueña del Producto y que va en contra vía del principio de transparencia en Scrum. Toda información relevante para la construcción del producto, debe ser conocida por todos los miembros del equipo e interesados.
4. Y, como punto de bonificación, he escuchado a personas en las empresas decir que esas actividades realmente no generan valor al usuario.
¿Y cómo sacar la pata?
Lo primero es tener claro que, si algún ítem del Backlog del Producto no tiene valor para el producto, el equipo no debería desperdiciar su energía desarrollándolo. Kenneth Rubin nos dice en el libro Scrum Esencial que “para que una historia técnica exista, la Dueña del Producto debe entender por qué pagar por eso y, por consiguiente, qué valor se va a entregar”. Scrum ofrece varios escenarios para que el Equipo de Desarrollo y la dueña del Producto mantengan comunicación constante que optimice el valor del producto al finalizar cada Sprint.
No considero cierta la división entre historias funcionales o técnicas en el Backlog del Producto. Mucho menos puedo creer que un ítem no funcional no afecte historias de usuario. La Dueña del Producto y el Equipo de Desarrollo pueden aprovechar el refinamiento de historias como el escenario para compartir los hallazgos que lleven a la creación de historias técnicas y colaborar juntos para definirlas, entenderlas, detallarlas y priorizarlas. En ese sentido, las personas en la organización, ajenas al Equipo Scrum, deben respetar las decisiones de la Dueña del Producto y ofrecer toda la confianza, responsabilidad y apoyo para aclarar la visión del producto.
Finalmente, Kenneth Rubin nos dice que “las historias técnicas no deberían estar en el Backlog” y tiene toda la razón. Estas historias siempre están asociadas a alguna historia de usuario con valor para el negocio. Si el Equipo de Desarrollo identifica que mejorar un algoritmo de ordenamiento es valioso para el producto, hay que identificar cómo ese valor va a llegar al usuario final. Equipo de Desarrollo y Dueña del Producto identificarán cuáles son las funcionalidades afectadas y escribirán las historias de usuario que tendrán como tareas asociadas la mejora de los algoritmos de ordenamiento.
Para cerrar cabe recordar que una cosa es hacer Scrum y otra cosa es hacer otra cosa. Hay incontables prácticas ágiles que se pueden implementar. Si vas a hacer Scrum, haz Scrum; si no lo vas a hacer, no digas que lo haces. Un mojito sin ron es una aromática fría, no un mojito.
