Saltar al contenido

Cómo estimar y planificar en SCRUM

plan scrum

Meterse en cómo estimar y planificar a largo plazo en Scrum es como meterse de lleno en un pantano de arenas movedizas. Cualquier movimiento que hagas, te hunde más, por lo que lo mejor es mantener la calma y pensar en cómo salir airoso de allí.

Si vienes de gestión de proyectos a la vieja usanza, lo primero de todo es utilizar uno de los bolis que utilizaban los agentes de Men in Black para olvidar todo lo aprendido en estimación y planificación hasta el momento.

Cuando las organizaciones deciden implantar Scrum, lo primero que suelen pedir es como se les queda el Gannt de proyectos y entregas para hacerle seguimiento. Es difícil hacerles entender que lo que antes era un Gannt ahora es un Product Backlog, donde priorizamos y estimamos a mayor nivel lo que vamos a entregar a máximo 3 meses vista, y el resto se mantiene priorizado, con una estimación de complejidad a alto nivel sin una fecha exacta de entrega.

En un inception obtenemos las historias de usuario del producto, estimadas por complejidad a alto nivel, normalmente por comparación con otras historias de usuario. Son historias de 8, 13, 20, 40 o 100 puntos.

A medida que se van ejecutando tareas del sprint backlog, y se aproxima la ejecución de las tareas del inception, es necesario hacer una estimación a mayor nivel de detalle. Por eso se convoca un refinement especifico de esas historias de usuario, para desglosarlas en tareas y hacer una estimación más precisa. Por experiencia, y en función de la duración del sprint, no conviene tener tareas en un sprint de más de 5 puntos, y si las hubiera, habría que partirlas para que no sean de más de 5 puntos.

A medida que se aborda una tarea con mayor nivel de complejidad, aumenta la incertidumbre y suelen ser las tareas que no conseguimos cerrar en el sprint.

Por eso, a medida que se acerca la ejecución de tareas del backlog, es necesario hacer una estimación de mayor nivel para afinar más la estimación y acordar con el usuario las entregas en el sprint.

Índice

    ¿Cómo conseguir una planificación anual en Scrum?

    Como nos cuesta adaptarnos a la nueva forma de trabajar, en Scrum seguimos pidiendo una estimación anual de lo que vamos a entregar.

    Realmente nuestro equipo tiene una capacidad de entrega por sprint, que es lo que nos indica la cantidad de puntos que podemos abordar en un año.

    Como ejemplo, podemos considerar un equipo Scrum formado por 3 desarrolladores, más el Product Owner y el Scrum Master, que ejecuta sprints de 1 semana. Si su ritmo de trabajo es de 12 puntos por sprint, en 52 semanas que tiene un año, el equipo es capaz de hacer 624 puntos.

    Podríamos estimar a alto nivel los proyectos a abordar en ese año, por comparación con otros proyectos, para darnos una estimación de la capacidad para abordar los proyectos. Es una forma, poco precisa, pero que muchas veces nos piden.

    ¿Deberíamos planificar los 624 puntos? La respuesta es no. No toda la capacidad es para desarrollo de nuevas iniciativas. Si el equipo da soporte a otros productos ya en el mercado, deberá atender las incidencias que surjan, o también cambios menores solicitados de esos productos. Esto hará que no podamos dedicar el 100% de los puntos al desarrollo de las iniciativas del año.

    Por eso se definen los conceptos de Estratégico, Táctico e Incidencias:

    • Estratégico: Son todas las tareas relacionadas con el plan de proyectos anual.
    • Táctico: Son todas las tareas para el mantenimiento y la actualización de los sistemas actuales que no formen parte del plan de proyectos anual.
    • Incidencias: Son todos los problemas que surgen de los productos que ya tenemos en producción.

    Habrá equipos donde la dedicación pueda ser del 60%,30%,10% (Estratégico, Táctico, Incidencias), otros donde sea 30%,50%,20% en función del grado de madurez de los productos.

    Para la planificación es importante que de la capacidad del equipo saquemos el porcentaje de Estratégico que puede dedicar y sobre ese número de puntos poner el límite en nuestro backlog anual para saber cuántas iniciativas podríamos abordar ese año de forma estimativa.

    El resto de historias que queden en el backlog, previsiblemente no podrían ser abordadas, a no ser que se reprioricen o la estimación a alto nivel, al profundizar, sea de menor complejidad y nos permita abordar más historias.

    ¿Cómo ir actualizando la planificación a medida que vamos entregando productos en Scrum?

    Como comentábamos, lo ideal sería que tuviéramos estimado a mayor nivel de detalle los próximos 3 meses, sobre todo y con mayor detalle el sprint siguiente y el posterior si hubiera capacidad.

    Esto hace que a medida que vayan pasando los sprints, nuevas historias entren en ese margen de 3 meses y sea necesario estimarlas a mayor nivel de detalle.

    Para no atacar las historias de forma individual, lo ideal sería hacer un refinement especifico del inception inicial de la siguiente reléase a entregar cuya primeras historias entran en el margen de los 3 meses.

    Bajando a mayor nivel de detalle seremos capaces de desgranar las historias y afinar más su estimación, consiguiendo una visión más clara de cuando podríamos tener los siguientes entregables.

    No hay nada a ciencia cierta y la transición entre Gestión de Proyectos a la vieja usanza y Scrum no es inmediata, con lo que probablemente debamos buscar los medios para garantizar una correcta transición siempre sin perder el foco de Scrum, que nos garantice una entrega continua adecuada a las necesidades de nuestros clientes.