La meta del Sprint es un elemento bastante desconocido en Scrum, así como su relación con el empirismo. En este artículo hablamos de ello.
La meta del Sprint es el principal elemento que no se entiende bien en Scrum y esto tiene un grave impacto. Este artículo explica para qué tener metas en los Sprints.
El empirismo y los proyectos predictivos
En todos los cursos Professional Scrum se habla del empirismo. ¿Qué es esto? El empirismo es la teoría filosófica que afirma que la principal fuente del conocimiento es la experiencia. ¿Y en qué se relaciona el empirismo con el desarrollo de software?
El desarrollo de software, ya sea en un contexto de proyecto de desarrollo de producto, presenta diferentes niveles de complejidad según factores como el trabajo a hacer (alcance), la tecnología a utilizar (más o menos conocida y madura) y especialmente la complejidad de la organización (gente). En los proyectos cuya complejidad es baja, es posible definir con precisión el alcance y el plan de trabajo conducirá a entregarlo con éxito. Pero esto pasa pocas veces y debemos comenzar el desarrollo con un nivel más o menos grande de incertidumbre.
Si damos una solución cerrada a un problema desconocido, tenemos una receta perfecta para un proyecto conflictivo con desviaciones en tiempo, presupuesto y calidad, así como insatisfacción del cliente con el resultado.
El diagrama de Stacey nos muestra las zonas de complejidad del proyecto.
Scrum nos propone un enfoque inteligente que puede combinar una estimación inicial del trabajo, para acotar el riesgo de presupuesto y plazo, con un descubrimiento progresivo del producto a desarrollar basado en el control empírico de procesos para maximizar la satisfacción del cliente con la solución dada.
El primer paso es descomponer los objetivos del proyecto en una lista ordenada de paquetes de trabajo, el conocido Product Backlog, que estará priorizado por la importancia de negocio de estos paquetes. Aquellos objetivos que presenten incertidumbre no se detallaran artificialmente con supuestos, sino que se reconocerá dicha incertidumbre y, en el momento de abordarlos, se planteará un plan de trabajo a corto plazo (p.e. 1, 2, 3… sprints) basado en objetivos más pequeños que permitirá validar individualmente las hipótesis y riesgos. No llamo a estos ítems de trabajo ni temas, épicas, historias, escenarios de BDD u otros nombres concretos, porque en Scrum no hay nomenclaturas estándares.
El siguiente paso es obtener este aprendizaje empírico durante los Sprints y sus eventos. Este aprendizaje es empírico por obtenerse de discusiones concretas sobre aspectos que se van conociendo, p.e. validar si una funcionalidad satisfará al usuario mediante compartir una maqueta gráfica, o si una tecnología será adecuada realizando un experimento técnico. Además, dicho aprendizaje es compartido entre todos los miembros del Equipo Scrum y aquellas figuras relevantes que tengan algún interés e información útil para el proyecto (Stakeholders), lo que enriquecerá la calidad de las decisiones contando con las opiniones de un conjunto amplio de personas.
¿Qué aporta la meta a un Sprint?
Uno de los elementos más incomprendidos de Scrum, al igual que los Sprint Review, es la meta del Sprint. De hecho, de las personas que conozco que saben o practican Scrum, pocas lo usan correctamente.
La Meta del Sprint tiene como objetivo dar autonomía al equipo en la toma de decisiones, especialmente durante Sprints con un nivel de incertidumbre medio o alto. Scrum es un marco de trabajo aplicable a un amplio rango de proyectos u otro tipo de problemas, y entre ellos hay proyectos de baja complejidad. En estos, los requisitos pueden determinarse fácilmente antes de comenzar el Sprint y típicamente no surgirán muchas al equipo respecto al resultado esperado del Sprint. Aún así la Meta del Sprint proporcionará beneficios, principalmente:
- Foco para ayudar a no hacer trabajo no relacionado con el objetivo, motivo por el cual descarrilan muchos Sprints.
- Autonomía para poder priorizar elementos del Sprint Backlog, según se corresponan más o menos con la meta.
- Autonomía al equipo para poder tomar decisiones funcionales sin necesitar consultar al Product Owner.
- Motivación para el Equipo de Desarrollo al comprender la importancia
Cabe resaltar que una visión potente del equipo de desarrollo le otorga capacidades como el análisis funcional o la definición y ejecución de las pruebas, y no siguiendo el patrón falsamente obligatorio que todo esto debe hacerlo el Product Owner.
En los proyectos de mayor complejidad es difícil determinar los requisitos antes de iniciarse el desarrollo, incluso antes de comenzar el Sprint concreto donde se desea construir algo. Es en estos donde la meta del Sprint puede tener un papel determinante.
Imaginemos que el Product Owner tiene un objetivo de negocio, p.e. disminuir un 50% el número de compradores que dejan el carrito sin completar en un comercio electrónico. Este objetivo puede utilizarse durante el Refinamiento del Sprint para descubrir los ítems del Backlog que intenten conseguir dicho objetivo durante el siguiente Sprint. En este nuevo Sprint la Meta estará clara y su alcance también. No se podrá validar la hipótesis de negocio hasta obtener datos de los usuarios, tras haber desplegado posiblemente durante el Sprint, pero eso no quiere decir que la Meta no le sirva al Equipo de Desarrollo para guiar el desarrollo del Sprint.
La meta del Sprint tiene otros muchos usos, pero he querido destacar algunos de los más importantes en este artículo. También me gustaría gustaría escribir respecto a la relación entre el empirismo y el significado de «Ready», pero eso será más adelante. 🙂
