De tantos sitios a los que vamos, en los que nos enseñan cómo están organizando su desarrollo, su negocio alineado con tecnología, la creación de tecnología, procesos, software… llámalo agilidad, como es lógico, hay algunas cuestiones, dudas, quizá problemas, que son repetitivos y frecuentes. De hecho, cuando algo es una cuestión repetitiva suelo dedicarle un post e ir contándotelo de vez en cuando.
Hoy quiero hablarte de uno de estos temas: “hay vida más allá del product backlog”, o más bien, mejor dicho, mas que “más allá”, lo que hay, o debería haber, es vida antes del product backlog.
En algunos equipos, mucha gente tiene dudas de cómo se llega a tener un product backlog, cómo se llega a obtener esas historias de usuario, parece como si “la agilidad” hubiese olvidado esa parte, como sino existiera nada más allá, ni técnicas, ni prácticas, pero… eso no es del todo correcto. De hecho, hay varias técnicas que se usan frecuentemente para llegar al product backlog, si bien, y a los hechos me remito, no deben tener la popularidad merecida, dado el desconocimiento de las mismas.
Por ejemplo, y como premisa antes de entrar en otras técnicas, una de las primeras ideas a tener claras es que el trabajo sobre el product backlog es constante, no vaya a ser que con lo siguiente que te voy a contar intentes cerrar un product backlog completo, con 200 necesidades, ante de empezar a desarrollar (eso sería un cascada en toda regla). Mientras el equipo crea un prototipo el Product Owner trabaja en las historias que probablemente, a falta de estimación, se desarrollarán en el siguiente Sprint y esto es lo que se llama “Dual-Track” o Continuous Discovery, como te conté en aquel Agilidad, ¿En qué momento hay que descubrir nuevos requisitos? Constantemente #ContinuousDiscovery
Claro que existen numerosas técnicas para el Product Owner, para su tarea constante de ir creando y evolucionando el Product Backlog. De casi todas ellas ya te he hablado alguna vez, son las que refieren más al Product Owner, que es el responsable del Product Backlog, son técnicas como los “inception”, también algunos meten también aquí el Design Thinking, si bien no es necesariamente ágil, o los “mapas de historias de usuario”.
Y hoy me quiero, precisamente, detenerme en este último, los mapas de historias, y compartir una reflexión al respecto. Resumidamente, para más detalle puedes ver el enlace anterior, un objetivo que persiguen los mapas de historias de usuario es hacerte pensar en qué debe cumplir el producto, en qué orden y evitar un típico fallo cuando se hacen entregas incrementales: entregar características que, en principio, son de alto valor para el negocio, pero son inservibles porque dependen funcionalmente de otras que tenían menos valor y no fueron implementadas.
El caso es que cuando 233 Grados de TI empieza a ayudar a algún equipo a pasar a trabajar de manera ágil, una de las primeras cosas que hacemos es un taller – mapa de historias de usuario. Y en el 99% de las ocasiones, con equipos de negocio maduros, para productos y negocios maduros, etc., es sorprendente ver como… no se tiene claro qué debe hacer, o hace, un determinado producto – servicio basado en software.
De hecho, cuando arrancamos los talleres de mapas de historias de usuario hay un montón de debate. Debate que no hubiera aparecido si se hubiese pretendido completar sin más un Product Backlog simple. Si el debate es mucho, o intuimos que hay demasiado desconocimiento de qué debe cumplir el producto pasamos a un “inception”.
En cualquier caso, a lo que iba es que después de ya muchas veces haciéndolo, comenzando la transformación ágil haciendo uso de mapas de historias de usuario, y viendo como entran al taller equipos de negocio seguros de que sabían que quería que hiciera el producto – servicio… y saliendo con la sensación de “pues no lo teníamos tan claro”, hoy, me parecería un suicidio que alguien empezara su mejora “a lo ágil” sin hacer un mapa de historias o técnica similar.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024