Cuando se trabaja en un proyecto Agile, el equipo planifica el trabajo para los próximos sprints mediante la creación de historias. Una historia define una sola actividad encapsulada en funcionalidad con descripción y criterios de aceptación.
Los sprints suelen durar de dos a cuatro semanas. Dentro de ese tiempo, el equipo necesita comprender cuánto contenido pueden tomar en un sprint para que aún puedan hacerlo dentro del tiempo de sprint dado.
En un proyecto no ágil, estimaría el trabajo generalmente en días-hombre. Eso significa cuántos empleados de tiempo completo necesita para completar esta actividad. En ese caso, siempre piensa en los días y la cantidad de personas al crear estimaciones.
En un proyecto ágil, las cosas son diferentes. Ya no cuentas días ni personas para calcular el presupuesto final. De hecho, prohibiremos incluso calcular el esfuerzo en algo así como días-hombre. En su lugar, deje que el equipo convierta a un valor generalmente aceptado para la historia que representará la estimación general.
Ahora, para saber cuál es exactamente el valor, esto realmente no importa. Es cierto que el representante más común de las estimaciones de historias son los Story Points. Esos son básicamente números de Fibonacci que comienzan con 0, 1, 2, 3, 5, 8, 13, 21, etc. El siguiente valor es la suma de los dos números anteriores. Esto ayudará a diferenciar la complejidad general de la historia, ya que cada siguiente número más alto es significativamente más alto que el anterior.
Pero no es necesario ceñirse a los puntos de la historia. Pueden ser estimaciones de tallas de camisetas (XXS, XS, S, M, L, XL, XXL). Si desea ser realmente creativo, puede presentar animales de ZOO y usarlos para estimar el tamaño.
De cualquier manera, ahora se trata mucho más del sentir de todo el equipo sobre qué número (o animal) representa mejor la complejidad general de esta historia en particular. Definitivamente no se trata de la representación del tiempo. Al final, el equipo debe completar cada historia incluida en el sprint dentro de ese sprint. Entonces el tiempo ya está dado al principio y es un número constante.
Tabla de contenido
Componentes de la estimación de puntos de historia
Una estimación de punto de historia no se trata solo de cuán compleja/difícil es una historia en particular. Al estimar una historia, el equipo debe considerar varios aspectos y reflejarlos en el valor de la estimación final.
La estimación final es entonces un valor que representa una combinación de todos los aspectos formados en un solo número. Esto es lo que debe incluir dicha estimación.
#1. Dificultad técnica
Asumiendo que estamos 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, por supuesto, el enfoque correcto. El equipo lleno de expertos técnicos debe saber mejor cómo evaluar esa área de una historia. Aquí el equipo puede considerar varios enfoques o sugerencias, 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?
- ¿Qué tan complejo será implementar el algoritmo o la lógica del proceso?
#2. Dependencias Externas y Riesgos
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.
Historias donde todo lo que el equipo puede lograr por sí solo es lo más fácil 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á una prioridad, naturalmente. El equipo solo tiene que contar con ese factor y considerarlo dentro de la estimación.
Cuánto aumentará este factor en la estimación total dependerá principalmente de la experiencia previa del equipo y del “nivel de externalidad”. Por lo general, en algunos sprints, el equipo establecerá un sentimiento unificado natural de cuánto puede complicar esta dependencia de personas externas la finalización exitosa 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 una forma u otra, no es necesario construirlo desde cero. Más bien, el equipo puede reutilizar la solución ya creada para crear una nueva mucho más rápido.
De tal forma, este conocimiento puede rebajar 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 considerar jamás es el autoconocimiento de la antigüedad y la capacidad del equipo.
A medida que el equipo trabaje en conjunto y entregue varios sprints, las personas dentro se conocerán entre sí. Comenzarán a comprender quién sabe qué y qué tan bueno es en eso. Y una vez que todos conozcan al resto del equipo, juntos como equipo pueden considerar esto durante la estimación.
Si la historia se basa en alguna habilidad técnica concreta y esa habilidad está muy presente dentro del equipo, la realización clara de la historia no será tan complicada. O viceversa, si falta la habilidad necesaria en todo el equipo, entonces el equipo necesitará mucho más tiempo para abordar el tema, y lo reflejarán en la estimación.
Estimando la historia
Cada estimación de la historia debe ser un esfuerzo de equipo. Ninguna voz debería 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 solo valor que represente la estimación final.
El equipo puede hacer la estimación directamente durante la discusión de refinamiento del sprint (una reunión donde las historias se discuten y aclaran entre el equipo) o, alternativamente, pueden reservar un tiempo dedicado para hacer precisamente eso.
Ejemplo de proceso de estimación
Compromiso del Plan de Sprint
El equipo ahora tiene una acumulación de historias que ya pasaron por las sesiones de estimación. Idealmente, a las historias se les ha asignado (además del valor estimado final) también una prioridad para que el equipo sepa qué historias vendrán a continuación en el próximo sprint.
Aquí viene la sesión de planificación, donde el equipo elegirá algunas de las historias para el próximo sprint. La decisión sobre qué historias elegir debe basarse en lo siguiente:
✅ Historias con las prioridades más altas que el equipo considera primero.
✅ Una experiencia del equipo de cuántos puntos de historia son capaces de terminar en un sprint. Este conocimiento solo viene con el tiempo y la experiencia del equipo. Necesita varios sprints para afinar y obtener una comprensión adecuada de esta capacidad.
✅ No solo debes considerar el número total de puntos de la historia y la prioridad. Otra consideración es cómo las habilidades dentro del equipo se distribuirán entre las historias seleccionadas. Por ejemplo, si el equipo tiene solo dos desarrolladores front-end, es posible que no elijan solo historias que consistan únicamente en desarrollo front-end. Eso llevaría a sobreutilizar a los dos muchachos mientras que el resto del equipo no lo es tanto. Entonces, el conocimiento del equipo va de la mano con la efectividad de la creación de contenido de sprint.
factor de velocidad
Por encima de todo se encuentra la velocidad del equipo (para el próximo sprint). Este número no está relacionado con la cantidad total de puntos de historia de ninguna manera. Sin embargo, indica cuánto estará disponible el equipo para trabajar en el próximo sprint.
Para poder planificar con precisión el contenido de un sprint, juntamos ambos aspectos:
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 de transformación a un equipo ágil. Literalmente se siente como si necesitara «conseguirlo» antes de poder comenzar a trabajar en ese modo.
Este primer paso es, lamentablemente, también el más difícil. En algunos casos, lleva incluso años, especialmente en entornos corporativos estrictamente conservadores, donde el tiempo solo se queda estancado en el tiempo.
De todos modos, esto es lo que sucederá una vez que el equipo “lo consiga”:
- Ya no necesita calcular personas o días para saber cuándo se puede completar algo.
- El equipo aprenderá a crear historias tan complejas como para que encajen dentro de un sprint. Si una historia es más compleja, se divide automáticamente en más historias.
- El equipo tiene buenas estimaciones de cada parte del trabajo, y una vez que lo planifican para un sprint, sabes exactamente cuándo se debe.
- Aumentará la fiabilidad y la previsibilidad del equipo.
- Todas las personas dentro del equipo estarán “en la misma frecuencia”. Mirarán una historia y entenderán cosas similares. Tal vez después de un tiempo, ni siquiera se molesten en estimar. Ven el número en su cabeza y, dado que todos ven el mismo número, pueden comprometerse con historias en un sprint incluso sin esta estimación explícita.
Y esto es lo que suele pasar si el equipo sigue sin entender el proceso o la forma de trabajar:
- De alguna manera todavía se apegan a las estimaciones de días-hombre a la antigua. Lo convierten todo a días o personas involucradas. Los puntos de la historia o los números de Fibonacci significan la cantidad de días, ya sea directa o indirectamente, a través de varias transformaciones.
- El liderazgo compara los equipos en función de la cantidad de puntos de historia entregados en cada sprint. Esto está tan mal como podría estar. Entonces no se comprende un hecho sustancial: cada equipo estima los puntos de la historia de manera diferente. No hay absolutamente ninguna razón para esforzarse en sincronizar dos equipos para estimar sus historias de “la misma manera”.
- Mientras que el punto de la historia de un equipo significa dibujar un círculo, para otro equipo, podría significar dibujar una casa con un techo plano, cuatro ventanas y dos puertas. Y está totalmente bien.
- A veces, los equipos tienden a estimar casi todo entre dos y cuatro números diferentes. Tal vez porque temen que una historia tenga el número 123, alguien pensará que tiene algo que ver con la cantidad de días. Pero el hecho es que la escala de Fibonacci tiene una cantidad infinita de números. No necesitamos limitarnos solo a estimaciones de 3, 5 u 8. Seguramente podemos (y tal vez ya creamos las historias con ese propósito en mente para que sean así de complejas, en cuyo caso está bien), pero definitivamente no es necesario.
- La estimación es impulsada por personas mayores que predefinirán las expectativas de todo el grupo. Nunca debemos permitir que un miembro del equipo influya en la estimación. Todos tienen el mismo derecho a expresar su opinión y ser escuchados.
Ultimas palabras
Cambiar a una estimación ágil desde los enfoques más tradicionales no siempre es fácil y requiere adaptación, tanto para los equipos como para el liderazgo superior. Para que funcione, ambas partes deben entender el proceso. Si uno de ellos no comprende, el período de transición es un camino difícil lleno de expectativas contradictorias.
Pero una vez que todo se transforme, algunas cosas mágicas comenzarán a suceder. Los equipos podrán estimar y planificar mejor su trabajo, y el liderazgo tendrá lanzamientos y hojas de ruta más predecibles en los que confiar.
A continuación, echa un vistazo a los procesos no saludables que pueden arruinar tu sprint.