En Redradix, cuando entra un proyecto nos es muy útil hacer un taller de descubrimiento para lograr entrar en la cabeza del cliente y así iniciar un camino lleno de interacciones que nos ayude a remar en la misma dirección.
Estos talleres de descubrimiento nos ayudan a romper el mito del “cliente no sabe lo que quiere” respecto a su producto y a descubrir interesantes oportunidades de negocio de manera conjunta.
El output de estos talleres es una lista de funcionalidades priorizadas para el desarrollo del MVP, también conocida como PBIs (Product Backlog Items).
Entonces, ya tenemos una idea de nuestro producto y ya hemos categorizado esas ideas, ¿y ahora qué?
Ahora, lo que hacemos es trasladar estos PBIs a Historias de Usuario (HU) y reflejarlas en una herramienta de gestión de proyectos, que en nuestro caso es Jira.
Durante los primeros días del proyecto, se reúnen todos los miembros del equipo (Product Owner, Project Manager, developers y otros perfiles implicados) y conjuntamente van convirtiendo estos PBIs en HUs.
Objetivo del ejercicio
Pues no es otro que estructurar el chorrón de PBIs generado en el taller de descubrimiento para que tenga forma de producto y comenzar a priorizarlo.
En estas reuniones vamos analizando cada columna de PBIs y, mediante el diálogo, la experiencia previa y la intuición, organizamos el producto en épicas (grandes bloques de trabajo), HUs, tareas y subtareas u otros tipos de trabajos, como spikes (elemento del Product Backlog orientado a la investigación o experimentación, cuya finalidad es obtener el aprendizaje necesario para implementar la funcionalidad solicitada por el Product Owner o cliente) o concerns (dudas o inquietudes).
Algo que nos ayuda mucho a escribir las HUs es entender bien los flujos principales del producto y entender bien los outputs para incluirlos en los criterios de aceptación (requerimientos mínimos para dar por finalizada la implementación de la funcionalidad). De esta forma nos aseguramos de que estamos construyendo una funcionalidad lo más simple posible pero completa.
Lo ideal es escribir todas las historias de usuario principales durante las primeras semanas del proyecto para entenderlo como un todo y poder sopesar el trabajo. Pero no nos agobiemos, sabemos que todavía hay mucha incertidumbre, y por ello luego tendremos las sesiones de refinamiento.
Planning poker
A veces ayuda poder estimar lo que conllevaría implementar cada HU. Para ello, en alguna ocasión hemos jugado al planning poker. Una técnica de estimación y gamificación con la que se promueve la cohesión y la colaboración del equipo.
Para estas sesiones nosotros utilizamos la plataforma de Planning Poker Online, siguiendo la siguiente dinámica:
- El equipo del proyecto, junto con el Product Owner, se reúne de forma virtual un miembro del equipo se encarga de compartir la pantalla. Entre todos se hace un barrido de las HU que hay en el backlog y se intenta sacar una HU de referencia que permita estimar el resto de HUs. Si se usa la secuencia de Fibonacci, esta HU tendrá una estimación de 1 story point.
- Ahora ya podemos empezar. El Product Owner presenta al equipo una user story y prevé un espacio para preguntas, de manera que todas las personas de todas las disciplinas presentes la comprendan y partan de la misma base para poder hacer una estimación de cada uno de los ítems que la componen.
- El proceso de estimación comienza: se escoge el primer ítem a evaluar y cada participante, de manera individual y privada, asigna una carta de su baraja, según el esfuerzo que considere que se requerirá realizar. Si seguimos teniendo como referencia la secuencia de Fibonacci, una tarea estimada con 3 story points, será 3 veces más compleja que la HU de 1 story point escogida como referencia, si la hemos estimado con 8 story points es por que es 8 veces mas compleja, y así sucesivamente.
- Acto seguido, los participantes revelan al mismo tiempo su carta al grupo.
- Si todas las cartas coinciden, se asigna dicho valor al ítem y la estimación termina.
- Si las cartas son diferentes, se abre el debate sobre aquellos valores especialmente dispares. Así, la persona que asignó el valor más bajo y aquella que asigna el valor más alto son invitados a justificar su elección. Aquí es donde está la chicha. La mayoría de las veces cada disciplina va a pensar solo en su parte y en estas charlas se abren muchas puertas para entender bien cada funcionalidad y el esfuerzo completo.
- Una vez han sido expuestas las razones, se puede convocar de nuevo una estimación o escoger la carta más alta.
- Este proceso continúa hasta que se llegue a un consenso con todas las historias de usuario del backlog.
Venga, ya tenemos unas historias de usuario y una estimación inicial, pero aquí no acaba la cosa.
A lo largo del proyecto van a surgir nuevas dudas, los requerimientos podrán cambiar y seguramente nos atasquemos con imprevistos, pero para eso están las sesiones de refinamiento. En estas reuniones se revisan las HUs de nuevo entre todos los implicados y vemos si la descripción y estimación inicial siguen teniendo sentido o si, por el contrario, podemos mejorarlas porque vamos teniendo menos incertidumbre.
El resultado de estos refinamientos son HUs mejores definidas, nuevas HUs o incluso nuevas dudas. Estas sesiones de refinamiento en Redradix las celebramos una vez a la semana hasta que se reduce la incertidumbre (si, a veces parece que ese momento nunca va a llegar, pero siempre llega).
Y ¡voilà! !Ya tenemos un producto convertido en proyecto! Ahora solo hay que empezar a trabajar.