En Scrum, ¿qué papel tiene la toma de requisitos?

¿Para qué sirve la toma de requisitos? Es un ejercicio que consiste en averiguar lo que vamos a hacer, para a continuación, desarrollarlo. La toma de requisitos es una actividad muy importante, sobretodo en el mundo tradicional, donde necesitamos planificar antes de ejecutar y, para ello, necesitamos saber lo que queremos hacer.

Una vez trabajé como analista en el área de innovación de un banco. Estuvimos ocho meses analizando la “fase 1” y sin desarrollar nada de código. Ocho meses es suficiente tiempo para que un competidor que desarrolla ágilmente lleve al mercado un producto que pueda iterar varias veces para consolidarlo. Mientras, nosotros solo tenemos un documento Word que dice lo que queremos, pero sin aportar valor a nadie. ¿Os acordáis lo de software funcionando sobre documentación exhaustiva?

Scrum y la toma de requisitos clásica

¿Cómo propone Scrum que debemos hacer esta “toma de requisitos? Es curioso, como Scrum tiene muy poca propuesta en este aspecto, Scrum prefiere centrarse en la entrega, ir lo más rápido posible al mercado y recibir feedback. ¡Tiene sentido porque Scrum va de entregar valor! No va de hacer un proyecto en fecha, por eso no nos dice cómo debe ser la toma de requisitos.

Scrum da por hecho que hay un Product Backlog que contiene lo que vamos a hacer (con la información que tenemos hoy). ¿De dónde sale ese Product Backlog? Ese es el motivo por el que hay tanto debate en la comunidad acerca de cómo generar ese Product Backlog. Está el Sprint 0, Design Thinking, Conceptualización o Design Product. Todas estas técnicas al final no son parte de Scrum. Si somos capaces de sin eso, tener claro lo que queremos construir, ¿seremos más rápidos que nuestra competencia?

Scrum tampoco reniega de que sigamos esas prácticas, eso es cosa nuestra. Desde luego, Scrum no prohíbe, limita o prescribe una fórmula concreta, dejar libertad en ese aspecto.¿A alguien le importa cuántas horas se necesitaron para escribir el análisis funcional del Microsoft Word o del Google Docs? Usamos el software que mejor funciona y que más nos convence. Si reduces el tiempo en la toma de requisitos, puedes averiguar antes lo que el mercado demanda. ¡Esto es agilidad!

Los equipos más maduros en Scrum, con organizaciones que realmente lo soportan, creen que van a aprender más entregando algo pequeño y recibiendo feedback que tomando requisitos a muchos interesados para “no molestar a nadie y tener en cuenta todos los intereses”. Las expectativas de los interesados hay que gestionarlas, no obstante, eso no se debe traducir en un “haz lo que yo opino”. El ir al mercado nos da datos, y esos datos nos ayudan a defender y argumentar nuestras decisiones y nuestra estrategia.

La Definition of Ready como técnica de toma de requisitos

Un curioso caso es el Definition of Ready y Scrum. Hay parte de la comunidad que querría añadirlo, de hecho, estoy convencido que Jeff Sutherland sería partidario ya que dedica un capítulo entero en su libro “Scrum: Doing twice in the middle time”. La Definition of Ready es un acuerdo entre el Product Owner y el Development Team sobre lo que debe cumplir un elemento del Product Backlog (PBI) para poder entrar en el Sprint. Esto ayuda a preparar previamente los elementos y a ser más efectivo. Si nos fijamos, es lo mismo, si una organización necesita 5 horas de reunión para preparar cada PBI, entonces serán menos efectivos que otra organización que no lo necesite, ¡Por eso Scrum no se mete ahí!

El refinamiento: cómo trabajar en el futuro

En Scrum, la única acción que trabaja los requisitos futuros es el Refinamiento. Mi compañero Youssef comentaba que, para él, el refinamiento podría ser el sustituto de ese Definition of Ready. El motivo es simple, en el refinamiento es donde debemos trabajar el futuro del trabajo que va a acometer el Development Team. Además, en el refinamiento se cuenta con el propio Dev. Team, por lo que se pueden plantear dudas o aclaraciones, esto sirve al Product Owner para trabajar sobre los elementos del Product Backlog de cara a que hagamos una mejor Sprint Planning.

Es cierto, que en Scrum se recomienda que no usemos más del 10% del tiempo del Development Team para hacer la labor de refinar. Es bueno hablar del futuro, aclarar dudas o adelantar problemas, pero centrémonos en la entrega. Es mejor aprender tras una entrega, que analizar en exceso un requisito sobre el que desconocemos el impacto que tendrá hasta que lo pongamos a disposición del usuario final.

Todo aquello que no hayamos refinado, llegará “verde” a la Sprint Planning. Esto provocará que el evento se alargue y pueda “atascar” al Development Team. Hay que saber equilibrar entre hiper-refinar y no hacer nada. ¡La virtud está en buscar el punto medio que nos funcione!

La toma de requisitos viene heredada de la mentalidad proyecto

Si te fijas, en la mentalidad de proyecto es normal invertir mucho tiempo en la toma de requisitos y el análisis porque nos lo jugamos todo en una fecha de fin. En Scrum primamos la entrega y por eso no nos interesa invertir mucho en eso. Un KPI que podemos utilizar es el “On product index” que mide el tiempo de reuniones. Una vez un compañero me dijo que su equipo tenía problemas porque “invertían mucho tiempo en reuniones”. Dado que eso era una opinión, le propuse medirlo de cara a convertir la opinión en hechos. Una técnica que podemos utilizar es la siguiente. Cada vez que termines una reunión y vuelvas al sitio del equipo cogéis un post-it y anotais, duración, cuantas personas, y motivo. Ese post-it se pega en una pared cerca del equipo, cuando finalice el Sprint analizamos todas las reuniones tanto cuantitativamente y cualitativamente ¿Podríamos haber obtenido un resultado igual con menos tiempo de reunión? ¿Cómo podríamos productivizar las reuniones?

A cambio, Scrum pone muchísima energía en la entrega, en que cada Sprint terminemos cosas y las entreguemos. Esa es la verdadera esencia de Scrum. Por eso se habla tanto de Definition of Done, por eso la Sprint Review es tan relevante y por eso hablamos de equipos multidisciplinares (equipos con todas las habilidades para terminar producto). Todo está pensado para eso y no tanto para la toma de requisitos.

He visto a equipos tener problemas en la entrega final acusar de todo al análisis y poner fases de análisis de seis meses, ¡en el año 2019! Deja de buscar el análisis definitivo para construir el producto final, el mercado es caótico, solo vas a conseguir que funcione probando, entregando, aprendiendo, inspeccionando y adaptando. Scrum nos brinda esa oportunidad, esta es la clave y madurar de verdad lo que significa es lo que dará a nuestra organización una ventaja competitiva.