¿Cómo estimar los puntos de historia para su proyecto?

Cuando se trabaja en un proyecto ágil, el equipo planifica el trabajo para los próximos sprints creando historias. Una historia define una única actividad encapsulada de funcionalidad con descripción y criterios de aceptación.

Los sprints suelen durar de dos a cuatro semanas. Dentro de ese tiempo, el equipo tiene que entender cuánto contenido puede incluir en un sprint para poder llegar a tiempo.

En un proyecto no ágil, se estimaría el trabajo normalmente en días-hombre. Es decir, ¿cuántos empleados a tiempo completo necesita para completar esta actividad? En ese caso, siempre se piensa en los días y en la cantidad de personas al crear las estimaciones.

En un proyecto ágil, las cosas son diferentes. Ya no contará días ni personas para calcular la estimación final. De hecho, prohibiremos incluso calcular el esfuerzo en algo así como días-hombre. En su lugar, usted deja que el equipo se convierta en un valor generalmente aceptado para la historia que representará la estimación global.

Ahora bien, cuál sea exactamente el valor, esto no importa realmente. Es cierto que el representante más común de las estimaciones de historias son los Puntos de Historia. Son básicamente números de Fibonacci que empiezan por 0, 1, 2, 3, 5, 8, 13, 21, etc. El siguiente valor es una suma de los dos números anteriores. Esto le ayudará a diferenciar la complejidad general de la historia, ya que cada número inmediatamente superior es significativamente mayor que el anterior.

Pero no tiene por qué ceñirse a los puntos de la historia. Pueden ser estimaciones de tallas de camisetas (XXS, XS, S, M, L, XL, XXL). Si quiere ser realmente creativo, puede introducir animales del ZOO y utilizarlos para la estimación de tallas.

De cualquier forma, ahora se trata mucho más de la sensación de todo el equipo sobre qué número (o animal) representa mejor la complejidad global de esta historia en particular. Definitivamente, no se trata de la representación del tiempo. Al final, el equipo debe completar cada una de las historias incluidas en el sprint dentro de ese sprint. Así que el tiempo ya está dado al principio y es un número constante.

Componentes de la estimación de puntos de historia

Una estimación de puntos de historia no se refiere únicamente a lo compleja/difícil que es una historia concreta. Al estimar una historia, el equipo debe tener en cuenta varios aspectos y reflejarlos en el valor final de la estimación.

La estimación final es entonces un valor que representa una combinación de todos los aspectos formando un único número. He aquí lo que deberá incluir dicha estimación.

#1. Dificultad técnica

Suponiendo que estemos estimando historias para un equipo de desarrollo, la dificultad técnica de la historia será una de las primeras áreas en las que el equipo se concentrará por defecto.

Y este es, sin duda, el enfoque correcto. El equipo lleno de expertos técnicos debería saber mejor que nadie cómo evaluar esa área de una historia. Aquí el equipo puede considerar varios enfoques o pistas, como:

• ¿Cómo se compara esta historia con otras ya entregadas desde el punto de vista de la complejidad técnica?
• ¿Cuántos archivos de código tendrá que crear/actualizar el equipo para completar la historia?
• ¿Cuántos cambios de código adicionales generará esta historia en los procesos del sistema circundante?
• ¿Cómo de complejo será implementar el algoritmo o la lógica del proceso?

#2. Dependencias y riesgos externos

Uno se sorprendería, pero la mayoría de las veces, el éxito de las historias dentro del sprint del equipo depende de las contribuciones de otros equipos o personas externas al propio equipo.

Las historias en las que el equipo puede lograrlo todo por sí mismo son las más fáciles de estimar. Las cosas se complican si el equipo necesita ayuda externa para sus historias. Para las personas ajenas al equipo, esta actividad no será prioritaria, naturalmente. El equipo sólo tiene que contar con ese factor y considerarlo dentro de la estimación.

Cuánto aumentará este factor de la estimación total dependerá sobre todo de la experiencia previa del equipo y del "nivel de externalidad". Por lo general, en algunos sprints, el equipo establecerá alguna sensación unificada natural de cuánto puede complicar esta dependencia de personas externas la finalización satisfactoria de la historia.

#3. Factor de reutilización

La siguiente área a considerar es cuánto del contenido existente puede reutilizar el equipo para completar la historia. Obviamente, si algunas de las partes ya están presentes de un modo u otro, no es necesario construirla desde cero. Más bien, el equipo puede reutilizar la solución ya creada para construir una nueva mucho más rápidamente.

De este modo, este conocimiento puede reducir la estimación total, aunque normalmente (sin esta reutilización), la historia sería más compleja en función del contenido definido.

#4. Comprensión del propio equipo

Un factor notable que ninguna estimación basada en días-hombre puede tener en cuenta es el autoconocimiento de la antigüedad y la capacidad del equipo.

A medida que el equipo trabaje junto y realice varios sprints, las personas que lo componen llegarán a conocerse. Empezarán a entender quién sabe qué y lo bueno que es en eso. Y una vez que todos conozcan al resto del equipo, podrán tenerlo en cuenta durante la estimación.

Si la historia depende en gran medida de alguna habilidad técnica concreta y esa habilidad está muy presente en el equipo, está claro que la realización de la historia no será tan complicada. O viceversa, si la habilidad necesaria falta dentro de todo el equipo, entonces el equipo necesitará bastante más tiempo para adentrarse en el tema, y deberá reflejarlo en la estimación.

Estimación de la historia

Cada estimación de la historia debe ser un esfuerzo de equipo. Ninguna voz debe predefinir la complejidad de la historia. El objetivo final debe ser dejar que el equipo discuta la estimación hasta que todos los miembros estén de acuerdo en un único valor que representará la estimación final.

El equipo puede realizar la estimación directamente durante la discusión de refinamiento del sprint (una reunión en la que se discuten y aclaran las historias entre el equipo) o, alternativamente, puede reservar un tiempo dedicado a hacer precisamente eso.

Ejemplo de proceso de estimación

1. Elija una herramienta de estimación para que la utilice el equipo, algo como el póquer de planificación, el tablero Miro o similares.
2. Coloque una historia en el tablero. Deje que el equipo discuta las últimas ideas o preguntas sobre la historia. Asegúrese de que todo el equipo tiene pleno conocimiento de la historia y de que están preparados para la estimación.
3. Comience la estimación. Cada miembro del equipo debe elegir un número de la escala de Fibonacci.
4. Una vez que todos hayan estimado, miren juntos los resultados. Comience la discusión. Normalmente, el equipo se separará entre dos o tres números. Deje que las personas del extremo inferior expongan las razones por las que la estimación debe ser tan baja. A continuación, deje que las personas del otro extremo expliquen por qué la estimación final debería ser así de alta. El objetivo es poner sobre la mesa todos los argumentos, consideraciones y hechos para que todo el equipo esté de acuerdo en comprender lo que incluye esta historia.
5. Una vez terminada la discusión, deje que el equipo vuelva a estimar. La mayoría de las veces, el equipo pasará a una o dos cifras distintas. Repita de nuevo la discusión. Dependiendo del caso concreto, o bien el equipo se pondrá de acuerdo sobre el número final de entre las dos alternativas, o bien usted decidirá otra ronda de estimación.
6. La estimación sólo termina si todos los miembros del equipo están absolutamente de acuerdo con la estimación final. Debe ser un acuerdo de todo el equipo, no sólo de algunos individuos. Potencialmente, cada historia puede ser asignada posteriormente a cualquier persona del equipo. Por eso es importante que todos estén de acuerdo sobre la complejidad de la historia.

Compromiso del plan del sprint

El equipo tiene ahora un backlog con historias que ya han pasado por las sesiones de estimación. Lo ideal es que a las historias se les haya asignado (aparte del valor final de la estimación) también una prioridad, de modo que el equipo sepa qué historias entrarán en el siguiente sprint.

Ahora llega la sesión de planificación, en la que el equipo elegirá algunas de las historias para el siguiente sprint. La decisión sobre qué historias elegir debe basarse en lo siguiente:

✅ Las historias con las prioridades más altas el equipo las considera primero.

✅ La experiencia del equipo sobre cuántas historias son capaces de terminar en un sprint. Este conocimiento sólo se consigue con el tiempo y la experiencia del equipo. Se necesitan varios sprints para afinar y conocer bien esta capacidad.

✅ No sólo debe tener en cuenta el número total de puntos de historia y la prioridad. Otra consideración es cómo se repartirán las capacidades dentro del equipo entre las historias seleccionadas. Por ejemplo, si el equipo tiene sólo dos desarrolladores front-end, puede que no elijan sólo historias que consistan únicamente en desarrollo front-end. Eso llevaría a sobreutilizar a los dos chicos mientras que el resto del equipo no tanto. Así que los conocimientos del equipo van de la mano con la eficacia de la creación de contenidos del sprint.

Factor velocidad

Por encima de todo está la velocidad del equipo (para el próximo sprint). Este número no está relacionado en modo alguno con la cantidad total de puntos de historia. Sin embargo, indica la disponibilidad de trabajo del equipo para el próximo sprint.

Para poder planificar con precisión el contenido de un sprint, juntamos ambos aspectos:

1. Velocidad del equipo - Medida en días. Un miembro del equipo disponible durante un día completo equivale a uno en la velocidad del equipo. Por ejemplo, un equipo de 10 personas totalmente disponibles para un sprint de 2 semanas de duración equivale a una capacidad de equipo de 100.
2. Cantidad habitual de puntos de historiacompletados en un s imprimir - Se mide en puntos de historia. Esta cifra procede de la experiencia previa y está estrechamente relacionada con la velocidad del equipo.

Se necesita tiempo y práctica para encontrar el punto óptimo.

Beneficios y errores comunes

Es sorprendente lo mucho que los equipos están dispuestos a complicarse el proceso en el camino de la transformación a un equipo ágil. Literalmente, da la sensación de que hay que "conseguirlo" antes de poder empezar a trabajar en ese modo.

Este primer paso es, por desgracia, también el más difícil. En algunos casos, lleva incluso años, sobre todo en entornos corporativos estrictamente conservadores, en los que sólo el tiempo se atasca.

De todos modos, esto es lo que ocurrirá una vez que el equipo "lo entienda":

• Ya no será necesario calcular personas o días para saber cuándo se puede completar algo.
• El equipo aprenderá a crear historias sólo tan complejas como para quepan dentro de un sprint. Si una historia es más compleja, se divide automáticamente en más historias.
• El equipo dispone de buenas estimaciones de cada pieza de trabajo y, una vez que la planifican para un sprint, usted sabe exactamente cuándo hay que entregarla.
• Aumentará la fiabilidad y la previsibilidad del equipo.
• Todas las personas del equipo estarán "en la misma frecuencia". Mirarán una historia y entenderán cosas similares. Puede que después de algún tiempo, ni siquiera se molesten en estimar. Ven el número en su cabeza, y como todos ven el mismo número, pueden comprometerse con las historias en un sprint incluso sin esta estimación explícita.

Y esto es lo que suele ocurrir si el equipo sigue sin entender el proceso o la forma de trabajar:

• De algún modo, siguen aferrándose a las estimaciones de días-hombre a la antigua usanza. Lo convierten todo en días o personas implicadas. Los puntos de historia o los números de Fibonacci significan cantidad de días, ya sea directa o indirectamente, a través de diversas transformaciones.
• La dirección compara los equipos en función del número de puntos de historia entregados en cada sprint. Esto no puede ser más erróneo. Entonces no se comprende un hecho sustancial: Cada equipo estima los puntos de historia de forma diferente. No hay absolutamente ninguna razón para esforzarse en sincronizar dos equipos para que estimen sus historias de la "misma manera".
  • Mientras que el story point de un equipo significa dibujar un círculo, para otro equipo puede significar dibujar una casa con un tejado plano, cuatro ventanas y dos puertas. Y no pasa nada.
• A veces los equipos tienden a estimar casi todo entre dos y cuatro números diferentes. Quizá porque temen que una historia tenga el número 123, alguien pensará que tiene algo que ver con el número de días. Pero lo cierto es que la escala de Fibonacci tiene una cantidad infinita de números. No tenemos por qué limitarnos sólo a estimaciones de 3, 5 u 8. Seguramente podemos (y tal vez creamos las historias ya con ese propósito en mente para que sean así de complejas, en cuyo caso está bien), pero definitivamente no necesitamos hacerlo.
• La estimación está dirigida por personas de alto nivel que predefinirán la expectativa de todo el grupo. Nunca debemos permitir que un miembro del equipo influya en la estimación. Todo el mundo tiene el mismo derecho a expresar su opinión y a ser escuchado.

Palabras finales

Pasar a la estimación ágil desde los enfoques más tradicionales no siempre es fácil y cuesta acomodarse, tanto para los equipos como para los líderes de arriba. Para que funcione, ambas partes deben entender el proceso. Si una de ellas no lo entiende, el periodo de transición es un camino difícil lleno de expectativas contradictorias.

Pero una vez que todo se transforme, empezarán a suceder cosas mágicas. Los equipos podrán estimar y planificar mejor su trabajo, y la dirección dispondrá de lanzamientos y hojas de ruta más previsibles en los que confiar.

A continuación, eche un vistazo a los procesos poco saludables que pueden arruinar su sprint.