A raíz de una publicación en X (Twitter) sobre la inutilidad de poner fechas en Scrum, un usuario me hacía una pregunta completamente válida sobre como se gestionan entonces las expectativas cuando hay que comunicar cambios en nuestro producto, conseguir una ronda de financiación o gestionar dependencias con otros productos y servicios.
El mito: en Scrum no se planifica
Uno de los mitos más extendidos -y a su vez más fácilmente rebatibles- es que en Scrum no se planifica. Es precisamente al contrario. En Scrum se planifica. Mucho y muchas veces.
En Scrum la planificación no es un documento, es una actividad.
En Scrum planificamos el objetivo al que vamos a orientar nuestro trabajo durante un Sprint durante el Sprint Planning, un plan de trabajo para acercarnos a ese objetivo durante todos los días del Sprint en el Daily Scrum, qué trabajo vamos a realizar en futuros Sprints en el Sprint Review y por último, cómo vamos a mejorar la manera de trabajar en la retrospectiva del sprint.
Eso supone que para un Sprint de un mes hemos hecho docenas de actividades de planificación a distintos niveles de la organización de nuestro producto y nuestra organización.
De hecho, el uso de Scrum junto con otras técnicas como son los OKRs es perfectamente viable a través de herramientas como el Sprint Goal y el Product Goal.
Lo que evitamos en Scrum es prometer o jurar que algo estará listo para una fecha. Dicho esto, es perfectamente viable trabajar con fechas en Scrum. Veámoslo.
Planificación por fechas para comunicación y Marketing en Scrum
Una vez que tenemos un Product Backlog, podemos utilizarlo para elaborar un roadmap que nos permita comunicar a otras áreas de Product Management (Marketing, Ops) cuando preveemos que determinadas características estén disponibles.
Esto es relativamente sencillo si hacemos una gestión de Producto orientada a generar elementos del Product Backlog. Elementos que generan valor por sí solos, ya sea en forma de historias de usuario, casos de uso o historias épicas.
No tenemos más que contar los elementos que estamos entregando cada Sprint, hacer una media y estimar cuando una serie de elementos estará listo para la entrega.
Aunque este método puede pecar de ser simplista.
En ese caso es mejor utilizar uno de los siguientes métodos o una combinación de ambos:
Planificación por Releases
La función principal de planificar una release es agrupar una serie de elementos comunes a uno o varios objetivos de negocio. Posteriormente realizamos un plan conjunto de comunicación y/o marketing a los usuarios una vez que estén listos y disponibles.
Cuando tenemos una lista de, por ejemplo, 24 elementos del Product Backlog que conforman una release y sabemos que cada Sprint completamos cinco -de media-, una estimación razonable es pensar que en cinco o seis Sprints la Release estará lista.
Por supuesto esto no es una promesa grabada en fuego y hay que tener seguimiento en cada Sprint Review por parte de aquellos que estén interesados en el Producto -en este caso, Marketing o Comunicación- para que una vez que vayamos completando Sprints, puedan tener un seguimiento durante los Sprints Reviews. Porque los planes pueden cambiar.
Entiendo que además cuando se trata de planes de comunicación y mercado existe una cierta flexibilidad a la hora de que las campañas salgan antes o después.
Planificación por Product Goals
El Product Goal se introdujo en la guía de Scrum para facilitar la planificación, el foco y pensar más allá de un Sprint. Un Product Goal es un objetivo en torno al cual existen los elementos que tenemos en el Product Backlog y habitualmente será un objetivo de negocio de un tamaño mediano, que puede coincidir con el objetivo de una nueva feature de nuestro producto.
Así, un Product Goal puede ser: “Permitir el uso de IA para que los usuarios corrijan el contenido que están editando”. Este objetivo puede abarcar múltiples Sprints y varias decenas de Product Backlog Items.
La manera de estimar es la misma que anteriormente. Solo tenemos que tomar como referencia el número de PBIs que completamos cada Sprint y utilizarlo como punto de medida para compararlo con el total de PBIs que conforman nuestro Product Goal.
Por supuesto, esta manera de medir y estimar es básica y recomiendo pasar rapidamente a maneras más precisas como puede ser el uso de simulaciones de montecarlo.
Planificación orientada a financiación o conseguir una ronda de inversión
Este caso es común en Startups o en organizaciones que hacen rolling Planning financiero para asegurar la financiación de nuestros productos. Aunque lo comentado anteriormente puede ser perfectamente válido, tenemos que subir un peldaño y mirar las cosas desde una perspectiva de negocio.
Cuando una startup está buscando financiación lo hace para satisfacer el modelo de crece o fracasa. Esto es, necesita cumplir hitos para buscar la siguiente ronda, ya que distintos inversores suelen entrar en distintos momentos.
Estos objetivos raramente tienen que ver con el producto en sí mismo, sino con términos de la propia empresa o financieros. El número de trabajadores. Volumen de leads. Clientes potenciales. Clientes recurrentes. Número de usuarios.
Es entonces cuando las cabezas pensantes se ponen a elaborar objetivos de producto que piensan que les pueden ayudar a completar estos objetivos.
Y la clave está en que lo piensan. No que vayan a cumplir con los usuarios, la recurrencia o los ingresos.
Merece la pena comentar que muchas startups evitan deliberadamente generar ingresos y prefieren crecer en base a una venta potencial futura.
En este caso, es interesante pensar directamente en los términos que se quieren llevar al pitch que se les va a dar a los inversores y trabajar con esos objetivos directamente como Product Goals.
Además, hay que tener en cuenta que hacerlo de esta manera nos va a permitir ser flexibles con el alcance de las fechas en scrum mientras nos centramos en los objetivos en lugar de completar todo lo que queremos realizar.
Dicho de otra manera. En lugar de centrarnos en completar una pila de cosas, nos centramos en los objetivos superiores y adaptamos lo necesario para cumplir con ellos. Porque no siempre lo que hemos estimado nos va a llevar a cumplirlos.
Como se puede observar, el Sprint es un pulso flexible para inspecciona y adaptar, no un lote que hay que completar a toda cosa.
Fechas en Scrum por obligaciones legales o dependencias con otros productos.
En este tercer caso tenemos fechas duras ya sea porque tenemos una obligación legal que cumplir o porque tenemos una dependencia con otro producto.
Cuando se trata de obligaciones legales el objetivo nunca debe ser estimar para ver como si podemos o no llegar a la fecha, sino tratar esta fecha como un factor de riesgo que nos va a obligar a cambiar el orden de nuestro Product Backlog.
En otros términos, no tiene sentido trabajar en cosas que no tienen riesgo cuando tenemos un riesgo que asumir.
Lo que ocurre en muchas organizaciones es que juegan al límite y retrasan cosas que pueden convertirse en un problema mientras trabajan en las pequeñas urgencias del día a día o en cosas que tienen menos riesgo.
El factor determinante en este caso no es si podemos estimar la fecha, sino si hemos adaptado nuestro Product Backlog y Product Goal para reflejar que la fecha existe.
Si se trata de dependencias con otros productos o servicios ocurre algo similar pero tenemos que diferenciar si son externos o internos.
En el caso de factores externo -por ejemplo, una tecnología que va a quedar desactualizada- lo tratamos igual que en el caso de las fechas por obligación legal.
Sin embargo, cuando se trata de productos o servicios internos sobre los que tenemos control, tenemos que trabajar para, a medio plazo, eliminar la dependencia y el acoplamiento de los productos mediante una estrategia adecuada.
Esta guía trata con los problemas más comunes de la gestión de fechas en Scrum. Si tienes cualquier otro o quieres matizar algún aspecto déjame un comentario más abajo. Y si quieres leer más tienes este otro artículo: Las fechas de entrega son sagradas.
Deja una respuesta