Cómo planificar a largo plazo en Scrum

Hoy día, para poder entregar valor, necesitamos sistemas de predictibilidad que nos permitan gestionar las expectativas de nuestros clientes, de la gerencia, adelantarnos a potenciales riesgos o eliminar dependencias. En el mundo del conocimiento es complicado averiguar exactamente cuándo estará el trabajo terminado, cuando conseguimos la inspiración, cuando resolvemos un problema que nos impide dormir, cuando un equipo será capaz de trabajar a máximo rendimiento o cuando un cliente nos enviará un email con información que nos desbloquea. Por tanto, planificar es positivo y difícil, explicamos cómo podemos aplicarlo en nuestros equipos Scrum. 

Estado del alcance

Imagina que, nos piden saber cuánto trabajo entregaremos en el próximo trimestre (quarter en inglés). Lo primero que tenemos que definir es el alcance, ¿qué es lo próximo que queremos hacer? Por ejemplo, podemos definir las próximas features que queremos incorporar y, sobre todo, ordenarlas. Es clave que, para esta ordenación contemos con stakeholders clave, como pueden ser: sponsor, gerencia, usuarios finales, representantes… 

Una vez lo tenemos ordenado, aterrizamos cada gran requisito en trozos más pequeños y manejables. Para esto, podemos utilizar varias técnicas, en función del reto que tengamos. A día de hoy, suelo utilizar: 

• MindMap  (Mapa mental): cuando tengo una funcionalidad que se incorpora en muchos puntos diferentes pero no es secuencial
• User Story Mapping (Mapa de Historias de Usuario): Si tenemos que realizar una feature que se describe como una secuencia de pasos o acciones. 
• Lean Inception: es muy útil cuando el desarrollo es muy grande o arrancando un nuevo producto. 

Es clave, en estos talleres, contar con personas técnicas, sobre todo porque, a veces, afecta técnicamente la manera en la que dividamos el alcance. 

Calcular nuestro Delivery Rate (capacidad de entrega) por Sprint

Para poder saber donde llegamos, necesitamos poder conocer nuestra capacidad de entrega. Necesitamos por tanto el histórico del equipo y, herramientas como Jira nos pueden ayudar. Tenemos que calcular cuántos items de trabajo somos capaces de entregar en cada Sprint y, posteriormente, usar este dato para plantear nuestra estrategia de producto. A continuación, tenemos los datos de un equipo real sacado de Jira, estamos viendo, por semana, cuantos items nuevos introducen y cuantos completan (nos quedamos con la segunda columna).  

Si utilizamos los datos de las últimas 20 semanas (10 Sprints del equipo), obtenemos los siguientes datos: 

Sprint 30	58
Sprint 31	67
Sprint 32	70
Sprint 33	83
Sprint 34	48
Sprint 35	60
Sprint 36	34
Sprint 37	43
Sprint 38	39
Sprint 39	46
Sprint 40	39

Y ahora, realizamos los siguientes cálculos:

Es decir, tenemos una media de 53 y una desviación de +- 15. O sea, tenemos un rango muy elevado. Aún así, podemos usar estos datos para ser predecibles. Si miramos en detalle los datos, tenemos semanas que Sprints de 83 items y otros de 34 items, es una diferencia demasiado elevada. Este equipo necesitará trabajar muy bien sus items para mejorar su predictibilidad. 

Planteamiento de escenarios

¡Comienza la magia! tenemos el alcance ordenado y tenemos nuestra capacidad de entrega. Si lo mezclamos, conseguimos diferentes escenarios que podemos plantear para gestionar expectativas y poder tomar decisiones adelantadas. Para ello, dibujamos los próximos Sprints e incluimos en cada uno de ellos el alcance esperado según el escenario planteado. 

El primer escenario sería el pesimista, siempre hacemos el valor inferior de nuestra capacidad, es decir, 53-15 = 38. Después hacemos el medio (53) y, por último, hacemos el caso optimista 53+15 = 68. De esta manera, disponemos de tres posibles situaciones con las que tomar decisiones. 

Lo positivo de esta técnica es que no solo usamos la media, sino que explicamos claramente qué podría ocurrir si el equipo entrega menos o si conseguimos ser capaces de producir mayor cantidad de trabajo terminado. Usar medias es jugársela a una sola opción, y deberemos de entender que nunca clavaremos la media. 

Seguimiento de la estrategia

Una vez hemos planteado nuestros escenarios, toca arrancar y hacer seguimiento. Cada vez que trabajemos el alcance deberíamos de actualizar nuestro plan de Sprints. En Scrum, esto ocurre en la Sprint Planning, porque decidimos el trabajo que podría entrar y cuál se quedará fuera. También puede ocurrir en cualquier refinamiento, ya que pensamos en el futuro, lo que supone que podamos alterar nuestro plan a largo plazo. 

Por otro lado, usaremos esta estrategia en la Sprint Review, ya que es un momento genial para compartir con personas ajenas al Scrum Team el camino que pretendemos seguir. De estas sesiones deberíamos obtener feedback, que usaremos para modificar nuestro plan y actualizarlo. 

La persona encargada será el Product Owner, es el responsable del seguimiento del Plan y de tenerlo actualizado. Esta información nos debe ayudar a gestionar expectativas. 

Alternativa con puntos de historia

Esta técnica de gestión de estrategia a largo plazo funciona cuando disponemos de datos, ¿y si nunca hemos trabajado antes? Podemos usar las recomendaciones del método Kanban, es decir, podemos hacer estimaciones (en puntos de historia por ejemplo) y sustituirlas por datos de historias de usuario a medida que tengamos datos concretos. 

Los puntos de historia miden la cantidad de trabajo que lleva un determinado item del backlog, para poder ponderar trabajos más grandes con otros más pequeños. Ahora bien, sigue siendo una técnica estimativa y no basada en datos, por eso es peligrosa. 

De esta manera, podríamos crear los tres escenarios basados en nuestra velocidad, es decir, en puntos de historia por Sprint. Siempre es mejor medir puntos que horas, es complicado explicar que hay escenarios donde hacemos “pocas horas” y otros donde hacemos “muchas horas”. De hecho, las horas tienden a la exactitud y, en un mundo complejo, la exactitud no es nuestra aliada. 

Y tú, ¿cómo planificar a largo plazo?