Planificar nuestro Roadmap cuando utilizamos Scrum como marco de trabajo.
Cuando pensamos en el futuro de nuestro producto visualizamos lo que queremos alcanzar en un mediano plazo (usualmente un año). Con esto surge la planificación de nuestro trabajo y a comienzos de un año o ejercicio generalmente creamos un Roadmap con diferentes hitos e intentamos asignarles fechas a cada uno de estos.
Si aplicamos metodologías ágiles, buscamos adaptarnos a todo cambio ocurrente, dentro y fuera de nuestra organización. Por lo tanto, el enfoque al planificar debería ser el mismo, deberíamos ser capaces de crear un Roadmap que se adapte a los diferentes acontecimientos, ya sea demoras en nuestras entregas, cambios de timón en la cúpula organizacional, circunstancias de fuerza mayor, entre muchos otros.
Estimar tiempos es la tarea más difícil, dentro del desarrollo de un producto, sobre todo cuando el nivel de desconocimiento es grande o total.
Frecuentemente cometemos el error de apegarnos a las fechas asignadas a cada hito de nuestro Roadmap, sin tener en cuenta si entregamos el valor deseado; o si nos retrasamos a cumplir las mismas sin evaluar el peso de la porción de trabajo que estuvimos realizando.
Para evitar encontrarnos en una situación donde el Roadmap planificado pase a ser obsoleto debido a los grandes cambios a los que nos enfrentamos día a día, sumados al desconocimiento de la “porción de producto” que hayamos planificado completar, deberíamos tener en cuenta los siguientes puntos:
- Planificar Objetivos y no Features.
- Planificar por etapas, siendo cada una de estas negociables con los Stakeholders del producto.
La razón de planificar objetivos evita encasillarnos sobre las funcionalidades que “en un primer vistazo” pensamos que contentarían a nuestros usuarios/clientes y stakeholders.
Para un primer acercamiento debemos asignar una “complejidad” para alcanzar el objetivo.
Estas complejidades podrían tener un período de tiempo asociado. Como un ideal usaremos trimestres para planificar ágilmente. Podríamos asignar 3 niveles de complejidad para alcanzar un objetivo:
- Complejidad Baja: 1 Trimestre
- Complejidad Media de 1 a 2 Trimestres
- Complejidad Alta 2 o + Trimestres (probablemente deba fragmentarse el desarrollo y/o objetivo)
Aquí tendríamos nuestra primera aproximación al Roadmap, esta sería de Alto Nivel y nos permitiría poner en una imagen con fechas tentativas nuestro plan anual.
El plantear objetivos en nuestro primer paso, nos facilitará, una vez comenzado el research del objetivo a atacar en el futuro inmediato, listar las Features que una vez construidas nos llevarán a completarlo. Es aquí donde bajaremos la estimación a un Segundo Nivel, esta debería negociarse con los Stakeholders exponiendo el resultado del research inicial.
En esta segunda etapa (por cada objetivo) tendríamos una planificación dinámica y un Roadmap que se ajuste a lo que descubrimos.
Una fase extra de la planificación debería llegar en checkpoints trimestrales. Donde revisemos desvíos y ajustemos nuevamente el plan, ya sea por nuevos focos del negocio, por retrasos, o en contrapartida: el adelanto a una fecha establecida en Alto Nivel ya que alcanzar el objetivo fue más sencillo o simplemente requirió menor trabajo del inicialmente esperado.
Esta planificación nos permite un Roadmap Dinámico y Negociable.
La planificación por adelantado no funciona en un entorno cambiante. Una vez que insistimos en un plan ideal por adelantado, es posible que no podamos reaccionar rápidamente a los cambios inevitables. En este caso, no usaremos Scrum para nuestro mejor interés.
Para tener éxito, debemos definir objetivos a alcanzar, en lugar de Features a implementar.
Quiero cerrar este artículo, con una frase de Marty Cagan extraída de “Inspired: How to create Tech products Customers Love” que me impulsó a desarrollar la idea previamente expuesta:
“Winning products come from the deep understanding of the user’s needs combined with an equally deep understanding of what’s just now possible.”
Ing. Esteban M Valeri