Una de las principales razones del fracaso en los proyectos ejecutados con scrum es la aceptación de los elementos correctos de la cartera de productos en el sprint. Sin embargo, el problema es mucho más difícil de resolver de lo que parece. Nos hemos dado cuenta de que es importante determinar qué criterios deben cumplir los productos pendientes (en nuestro caso, las historias de usuarios) para poder ser admitidos en un Sprint. Todo el mundo habla de la definición de listo, pero nadie pone ejemplos que puedan usarse en la vida real de forma inmediata. Por lo tanto, el objetivo de este artículo es contribuir con ejemplos de un proyecto terminado con una definición clara de Ready y el uso de Spikes que, en nuestra opinión y en los de nuestro cliente, fue una implementación extremadamente exitosa.
Las siguientes cinco sugerencias deberían ayudar a tu equipo a aclarar lo que hay que hacer y a ordenar las acciones antes de comenzar cada sprint. Hemos observado varias mejoras en nuestra empresa al tomar estas medidas específicas para que las historias de usuarios se acepten en los sprints. En primer lugar, el propietario del producto debe priorizar claramente los elementos en los que se espera trabajar a continuación. Cada uno de ellos debe incluir una descripción clara y unos criterios de aceptación que el equipo de desarrollo comprenda. En segundo lugar, contar con diseños adecuados que ilustren correctamente el requisito. Si no hay ninguno, se corre el riesgo de quedar abierto a la interpretación del equipo de desarrollo, lo que generalmente conduce a malentendidos e implementaciones incorrectas. Esto es especialmente importante en los casos en los que se debe desarrollar una interfaz compleja: es imprescindible contar con diseños preexistentes, disponibles y suficientes. En tercer lugar, si el proyecto requiere la integración con un proveedor o componente externo, siempre existe el riesgo de llegar al final del proceso y encontrar problemas en las API de la otra parte cuando queda poco tiempo. ¿Qué se debe hacer para mitigar este riesgo? Lo primero que se debe hacer en estos casos es una prueba ficticia para comprobar la conexión y sus parámetros. Es necesario analizar este elemento y su impacto en el producto antes de aceptar el artículo en el Sprint. Para ello, creamos un Spike, una historia de usuario para la que el equipo aún no puede estimar el esfuerzo necesario y necesita seguir evaluando el problema. Si lo haces con antelación, te anticiparás a los posibles problemas de conectividad que deberían corregirse antes de invertir horas de trabajo en una tarea sin salida que podría comprometer todo el sprint. Aunque técnicamente hablando, esta técnica no se basa al 100% en Scrum, es una herramienta que hemos demostrado ser útil para minimizar los remanentes del Sprint (una historia de usuario que no está finalizada, no se acepta y pasa al siguiente Sprint) y los impactos negativos. En cuarto lugar, aunque el propietario del producto es el responsable final de priorizar un artículo para el sprint, es posible que tenga otras necesidades relacionadas con las partes interesadas que podrían contribuir a decidir si incluir o no el producto acumulado en el Sprint. Sin embargo, para tomar esta decisión, las partes interesadas que han solicitado la función deben estar de acuerdo en cuanto a la descripción, los criterios de aceptación y cualquier otro activo antes de que pase a formar parte de la lista de productos pendientes de Sprint. En quinto lugar, es de suma importancia detectar si existen dependencias funcionales antes de añadir un elemento al Sprint. Por ejemplo: si una determinada historia de usuario solo puede existir si hay una preexistente de la que dependa, esta dependencia debería incluirse primero. Si esto se detecta una vez que el Sprint ha comenzado, hay muchas posibilidades de que el elemento del Sprint no esté terminado.
Cabe señalar que la definición de listo puede ser un arma de doble filo, ya que si uno es demasiado meticuloso al aceptar artículos en el Sprint, puede terminar no aceptando nada o muy poco. Por eso es importante tener anotada la cantidad correcta de lo que se debe hacer. Tener demasiadas cosas también puede tener un impacto negativo porque, en ese caso, uno siempre estaría escribiendo en lugar de hacerlo e intentando tener la definición perfecta cuando el objetivo es tener un software funcional que añada valor a la empresa lo antes posible. Scrum debe usarse en contextos inciertos basándose en los tres pilares bien conocidos: probar, validar y evolucionar. Tener todo extremadamente claro, como puede ocurrir en Definitions of Ready, puede ser una bendición a medias: el equilibrio es la clave.
Las acciones recomendadas anteriormente han demostrado tener consecuencias positivas para nuestra empresa. Mejoraron el rendimiento de nuestro equipo en aproximadamente un 86%. Mejoraron la confianza del equipo a la hora de aceptar historias de usuarios en el Sprint. Además, redujeron al mínimo la cantidad de actualizaciones acumuladas en más de la mitad de las funciones, en comparación con lo que hacían antes de implementar la mejora. También determinaron la necesidad de contar con más detalles o de desarrollar User Story Slicing. Por último, pero no por ello menos importante, anticiparon los problemas incluso antes de iniciar el Sprint.
Independientemente de si trabajas con Scrum internamente en tu empresa o para un cliente, organizar el proceso tiene enormes beneficios para todos. Si tu cliente o patrocinador cree que estás complicando un proceso que parece bastante simple al formalizarlo, intenta hacer algunos sprints de prueba como este. Los resultados se medirán con bastante rapidez y demostrarán tu punto de vista de inmediato.
¡Feliz juego de scrumming!
.svg)