Calcular la capacidad de un Sprint

Una pregunta que surge con frecuencia en proyectos Scrum es cómo calcular la cantidad de puntos de esfuerzo que los desarrolladores pueden asumir durante un Sprint. A esto se le llama « capacidad ».

En este artículo, veremos un método que funciona muy bien y que permite hacer estimaciones precisas en general.

El ideal de un agilista es trabajar en el concepto #NoEstimate (no estimar tareas), pero pocas empresas están dispuestas a adoptar este enfoque altamente ágil.

Los primeros 3 Sprints del proyecto

Durante los primeros 3 Sprints, consideraremos que aún no estamos lo suficientemente avanzados como para calcular automáticamente la suma de los puntos de esfuerzo permitidos, es decir, la capacidad. El Product Owner permitirá que los desarrolladores elijan la capacidad.

Los resultados de la velocidad de estos primeros 3 Sprints no serán necesariamente muy confiables ni constantes; se estima que se necesitan 3 Sprints para comenzar a tener una base utilizable.

Entraremos en detalles a partir de los Sprints siguientes.

Los Sprints siguientes

Existe un método efectivo para calcular la capacidad del equipo en un Sprint.

Fórmula de capacidad

Aquí está la fórmula mágica que lo ayudará y que explicaremos en detalle:

Co = ∑(V3) / ∑(Ca) * Cae

Explicaremos cada parte para realizar el cálculo:

∑(V3): suma de los puntos de esfuerzo reales de las historias de usuario que están en « Hecho » en los 3 Sprints anteriores.

∑(Ca): suma de los días/hombre de presencia de los desarrolladores del equipo en los 3 Sprints anteriores.

Cae: número de días/hombre estimados en el próximo Sprint.

Para simplificar, estamos calculando la cantidad de puntos de esfuerzo que los desarrolladores pueden lograr en el próximo Sprint en relación con los días trabajados.

Ejemplo para comprender

No todos son matemáticos, aunque las fórmulas no son muy complicadas, aquí tiene un ejemplo concreto para entender la fórmula.

Mi equipo A acaba de terminar el Sprint 3, y el Scrum Master debe informar al Product Owner la cantidad total de puntos de esfuerzo que se pueden permitir en el próximo Sprint (Sprint 4).

El Scrum Master ha registrado estos números en una tabla:

Velocidad al final del Sprint Días/Hombre trabajados

Sprint 1 45 30
Sprint 2 34 27
Sprint 3 50 29

También ha notado que el equipo trabajará durante 28 días en el Sprint 4 si no hay ausencias durante el Sprint no previstas hasta ahora.

Realizará el siguiente cálculo:

∑(V3) = 45 + 34 + 50 = 129
∑(Ca) = 30 + 27 + 29 = 86
Cae = 28

Entonces

Co = 129 / 86 * 28 = 42

El Scrum Master acaba de determinar que el Product Owner podrá proponer historias de usuario que en total sumen 42 puntos de esfuerzo.

Dado que no siempre es posible tener exactamente 42, el Product Owner puede proponer 43, 42 o 41 puntos de esfuerzo en total.

¿Y si mi Sprint termina antes?

Dado que esto es una estimación, es posible que los desarrolladores terminen un Sprint antes de tiempo (el Product Owner ha aprobado todo y todas las historias de usuario están « Hecho »).

Existen varias soluciones en este caso, las dos más utilizadas son:

• El Product Owner puede agregar historias de usuario pequeñas para que los desarrolladores no se queden sin trabajo.
• Se permitirá que los desarrolladores aprovechen el tiempo restante para investigar (Spike). Sin embargo, será necesario restar este tiempo de la capacidad del Sprint.

Los matemáticos entenderán rápidamente este tipo de reglas: si no se permite una proporción mayor de puntos de esfuerzo que antes, la cantidad de puntos de esfuerzo permitidos siempre disminuirá.

¿Y si una historia de usuario se vuelve a estimar?

Cuando una historia de usuario no se completa en un Sprint, se coloca nuevamente en el Sprint siguiente y se vuelve a estimar, ya que es lógico que su punto de esfuerzo disminuya (en raras ocasiones aumenta).

En este caso, aplicaremos el nuevo punto de esfuerzo para la suma de los puntos de esfuerzo permitidos (y para el Burndown Chart), pero tomaremos el punto de esfuerzo más alto registrado para el cálculo.

Por ejemplo, si una historia de usuario en el Sprint 2 tenía un punto de esfuerzo de 8 y al comienzo del Sprint 3 los desarrolladores estiman que ahora tiene un punto de esfuerzo de 5:

• Tomaremos 5 como el punto de esfuerzo para la suma de los puntos de esfuerzo permitidos del Sprint (y para el Burndown Chart).
• Tomaremos 8 como el punto de esfuerzo para la velocidad al final del Sprint. Es mejor mostrarlo en una tarjeta (o en el software):

Reestimar la complejidad Reestimar el punto de esfuerzo Es posible que no sea muy claro, pero es fundamental tomar el número más alto para realizar cálculos más precisos.

Determinar la capacidad

Se recomienda encarecidamente ofrecer un calendario de disponibilidad que muestre las ausencias de cada miembro del equipo en el proyecto. Esto será de gran ayuda para el Scrum Master al calcular la capacidad.

capacidad de los equipos capacidad de los equipos Es preferible que solo se muestren las ausencias, ya que es mucho más probable que se agreguen ausencias en lugar de quitarlas. Por lo tanto, los desarrolladores pueden anotar sus ausencias directamente en el muro (en esta visualización).

La base de las hojas de ruta

Sepa que gracias a este método, podrá crear hojas de ruta fiables (aunque sigan siendo estimativas) para sus proyectos. Estas hojas de ruta a menudo son esperadas por la dirección que aún no ha podido comprometerse por completo.

Atención al contexto

Si bien este método es útil, es importante prestar atención al contexto de la empresa. Este método no debe llevar a terceros a comparar días/hombre y puntos de esfuerzo.

El Scrum Master debe ser el defensor contra este tipo de comparaciones y considerar otras formas de previsión si la persona no está dispuesta a cambiar esta mala práctica.