El problema del carry-over en Scrum

Un problema relativamente común en equipos Scrum son los carry-overs, historias que no logran ser completadas en el sprint comprometido y deben, por tanto, ser reprogramadas para el siguiente. Los carry-overs, cuando suceden con frecuencia, muestran equipos Scrum que no son capaces de cumplir con sus compromisos, lo que afecta su predictibilidad y, consecuentemente, erosiona la confianza del cliente en los mismos.

Aunque puede haber varias causas para los carry-overs, una de ellas es la incapacidad de los equipos para lograr estimaciones consistentes; historias de igual tamaño relativo (story points) resultan tomando esfuerzo (horas-hombre) muy diferentes entre sí. Véase los dos gráficos adjuntos a manera de ilustración. En ambos se muestra la evolución del esfuerzo total real (horas trackeadas) que tomó implementar diferentes historias de 2 story points a lo largo de 5 sprints.

Nótese la diferencia entre ambos gráficos. Mientras en el primero se observa alta variabilidad del esfuerzo, el segundo muestra esfuerzos que a lo largo del tiempo son consistentes, lo cual indica que este segundo equipo es más predecible (por lo menos para las historias de dos story-points). En mi experiencia he encontrado pocos equipos del segundo tipo, lo usual es que algunos sean relativamente buenos estimando historias pequeñas, pero su efectividad disminuye con las historias más grandes; los equipos del tipo 1 son mayoría. ¿Por qué? A continuación algunas posibles causas, sin ningún orden en particular, y sugerencias para mejorar. Toda mención a ‘equipo’ se refiere a ‘equipo Scrum’.

Causa #1. Las historias estimadas no estuvieron suficientemente maduras

Algunas veces el equipo llega a las reuniones de estimación sin tener el conocimiento mínimo requerido (funcional o técnico) para poder estimar con cierta certidumbre. En situaciones como estas, lo mejor es no proceder con la estimación. Sin embargo, si las historias en cuestión son realmente prioritarias, podrían ser estimadas pero tomando nota de las asunciones, las mismas que deberán ser validadas cuanto antes. De ser necesario, una vez el equipo posea el conocimiento mínimo requerido, estas historias podrían ser reestimadas.

Una herramienta que ayudaría a validar rápidamente si una historia está lista para ser estimada sería un checklist de requisitos para estimación. Este checklist sería muy parecido al artefacto Scrum denominado ‘Definition of Ready’ (no confundir con ‘Definition of Done’) y debe ser consensuado por el equipo de acuerdo a sus propias circunstancias. Algunos ítems que podría contener son:

  • La historia debe estar escrita como una user story, esto es, “As a [tipo de usuario] I want [feature] so that [benefit]”.
  • La historia debe tener la aprobación del Product Owner.
  • La historia debe contener criterios de aceptación funcionales y no funcionales, si corresponde, y estos deben ser claros para todos.
  • Ninguna historia debe contener, en relación a funcionalidad existente en producción, definiciones del tipo “como actualmente funciona”; descripciones así dejan la responsabilidad funcional en manos del equipo técnico. Se debe tener documentada la funcionalidad deseada, sea de manera explícita o mediante una referencia a la documentación de una historia anteriormente implementada.

Causa #2. Falta de disciplina en la documentación de las historias

No es raro que, en medio de la reunión de estimación o incluso luego de iniciado el sprint, el equipo decida un cambio a cierta historia. Desafortunadamente tampoco es infrecuente que el cambio acordado no quede documentado. Y si bien en Agile (we value) working software over comprehensive documentation”, la buena documentación, esto es, simple y clara, siempre es importante para una buena comunicación.

Si las historias no están bien documentadas, el objetivo del sprint no estará igual de claro para todos (imaginemos, para empezar, a quienes no estuvieron presentes en una reunión). Entre otras, las consecuencias serán discusiones repetidas, retrabajo, sensación de desorden y desánimo, sin contar el impacto de cara al cliente/usuario.

No está de más resaltar que la documentación no es un fin en sí misma, el objetivo último de documentar es lograr una buena comunicación, expectativas claras, fácilitar el seguimiento. Hay que tener en cuenta esto al decidir cómo se documentará.

Causa #3. El equipo no hace tracking de sus actividades

Algunas veces, sea por falta de herramientas de control o por falta de costumbre en el uso de estas, los miembros del equipo no registran los tiempos de todas las actividades que ejecutan al implementar las historias, de modo que los reportes de horas-hombre por historia como los mostrados arriba no son confiables. Ni qué decir de otros reportes típicos como el burndown chart.

Normalmente, los equipos deben planificar sobre un 80%-90% de su tiempo teóricamente disponible. Así, para un día de 8 horas, lo mínimo que cada individuo debe planificar (y trackear) cada día es entre 6.4 y 7.2 horas. El líder del equipo debe asegurarse de que todos cumplan esta regla; al hacerlo no solo vela por la calidad de la información a usar para reportar la efectividad de las estimaciones sino porque, si no es visible que el equipo hace tareas productivas cada día, es fácil concluir, quizá erróneamente, que se puede prescindir de algunas personas.

Causa #4. El equipo Scrum no se prepara lo suficiente para estimar

Una vez que las historias están documentadas a un nivel mínimo aceptable, es responsabilidad de todos los miembros del equipo leer la documentación, hacer un análisis individual y preparar preguntas/plantear escenarios para el negocio, i.e. Product Owner/Business Analyst, antes de la reunión de estimación. En la medida en que se cumpla consistentemente con esta responsabilidad las discusiones de estimación serán productivas y las estimaciones tenderán a ser consistentes en el tiempo.

Desafortunadamente la ‘falta de tiempo’ es la ‘explicación’ más usual para justificar la falta de preparación en las reuniones de estimación; solo una parte del equipo estima con base en conocimiento funcional/técnico real - el resto solo ‘sigue la ola’. En este escenario es más probable que se pase por alto algunas actividades importantes o se incluya actividades innecesarias, siendo el primer tipo de error el más frecuente.

Causa #5. No existe un checklist para estimaciones

Dado el contexto de un equipo, esto es, experiencia, arquitectura, tecnología usada, sistemas legacy existentes, nivel de automatización, etc., es posible crear un checklist de actividades típicas (para implementar una historia) que ayude a reducir la posibilidad de que se obvie alguna actividad importante al estimar. Por ejemplo, un checklist simple podría incluir estos puntos:

  • Desarrollo requerido en backend
  • Desarrollo requerido en frontend
  • Casos de pruebas ya existentes para reusar
  • Nivel de automatización de pruebas existente para reusar
  • Nivel de data existente para pruebas
  • Nivel de dependencias externas

Con un checklist como este, probablemente las discusiones de estimación serían más específicas. Asimismo, sería más sencillo llegar a una estimación consensuada de manera estructurada, ordenada.

Causa #6. No consensuar los cambios

Muchas veces, por un cambio de prioridades del negocio o de condiciones del mercado, se necesita modificar el compromiso del sprint, o simplemente una historia. Un error usual en la gestión de estos cambios es que el líder del equipo o quien más cercanía tenga con el Product Owner, asume por su propia cuenta compromisos sin conversar antes con el resto del equipo. Así, por ejemplo, la nueva historia resulta requiriendo el doble de horas de pruebas que la historia inicial. La consecuencia será, previsiblemente, que algunas personas tendrán que trabajar más de lo que inicialmente ellas habían planeado - lo peor, sin que ellas hubieran participado de la decisión del cambio. Esta mala gestión del cambio tendrá consecuencias no solo de cara al cliente (carry-overs) sino también en la dinámica interna del equipo pues afectan negativamente la reputación y el ascendiente del líder sobre el resto.

Sugerencias de mejora

En resumen, para superar algunas de las causas que originan una baja predictibilidad de los equipos Scrum se sugiere:

  • Crear un checklist de validación de historias para que el equipo pueda confirmar si una historia está realmente lista para ser estimada.
  • Documentar los acuerdos y hacerlos visibles a todo el equipo. El Project Manager, el Scrum Master o el Technical Lead, no necesariamente en ese orden, debe velar por que esto suceda.
  • Reforzar la planificación y tracking del tiempo de todo el equipo para cada sprint. Esto es responsabilidad de cada individuo pero el Project Manager o Technical Lead debe asegurarse de que ocurra.
  • El Product Owner (o quien en el equipo tenga la responsabilidad funcional) debe tener reuniones con el equipo técnico antes y durante la elaboración de las historias. Esta práctica trae varios beneficios. Por un lado se tendrá historias más sólidas/viables técnicamente; por otro, se acercará el equipo técnico al negocio, logrando, en el mediano plazo, su empoderamiento y, en lo inmediato, menor esfuerzo (tiempo) para familiarizarse con las historias próximas a ser estimadas.
  • Crear un checklist con las actividades típicas que, dadas las circunstancias del equipo, se requieren para la implementación de una historias promedio.
  • Debe estar prohibido comprometerse con el negocio en algo si antes no ha sido consensuado internamente. Como regla general, antes de pronunciarse sobre la viabilidad/inmediatez de solicitudes de negocio ‘urgentes’, lo mejor es pedir ‘un tiempo’ para discutir el problema entre manos con el equipo y llegar a una respuesta consensuada.

Se aclara que en este artículo no se considera las reducciones en esfuerzo que se deban a mejoras en productividad. Es decir, si con el paso del tiempo se requiere menos esfuerzo (horas-hombre) para implementar historias del mismo tamaño en razón de mejoras en procesos del equipo, ello no debe ser considerado un problema. No obstante, si en nuestras gráficas de tamaño vs. esfuerzo de arriba las historias outliers se explican por mejoras en productividad, ellas deberían ser analizadas por separado.

Por último, las acciones sugeridas son solo sugerencias, no significa que vayan a funcionar en todos los contextos; cada equipo deberá ser creativo para encontrar las acciones más apropiadas para su situación particular. No obstante, sí debe quedar claro que, aunque las acciones de mejora deben ser adoptadas de manera consensuada, es responsabilidad última del Project Manager, en tanto accountable for the team’s performance, quien debe asegurarse de que haya planes de mejora en marcha (para carry-overs u otros problemas) siempre.

Karina Serrano

Gerente de proyecto de TI | Líder Scrum Master

2 años

Uno de los mejores post que le encontrado sobre mejoras para eliminar esa deuda tecnica o trabajo que no se alcanzo a terminar

Jesus M.

Technical Project Manager | Agile Consultant | Technical Leader | Multilingual Engineer

4 años

Guido Portalanza che por mucho es de los mejores post que he leído sobre agilidad, conciso, neutro y muy acertado. #Kudos

Hugo Piñango Salazar

Agile Coach Certified™ | Scrum Master Certified™ | DevOps Certified™ | Management 3.0 | OKR Design | Proyect Manager IT | PMI | Lean Change | Agile Leadership | Delivery Manager | Transformación Digital

4 años

Excelente amigo

Inicia sesión para ver o añadir un comentario.

Más artículos de Guido Portalanza

  • No necesitamos Scrum Masters

    No necesitamos Scrum Masters

    Cada vez más las organizaciones reclutan Scrum Masters con la esperanza de asegurar la efectividad de sus equipos de…

Otros usuarios han visto

Ver temas