La toma de requisitos es un elemento clave en cualquier equipo que tiene que trabajar unido. Necesitamos conocer cuáles son las fuentes de demanda y aprender a gestionar expectativas. Hablamos en su día que, en Scrum, no hay ninguna técnica propuesta, queda todo en responsabilidad del Product Owner que debe, a través de Product Management, de gestionar la toma de requisitos. Scrum se enfoca en la entrega sin entrar en de dónde salen los requisitos. Por tanto, voy a explicar las técnicas que suelo utilizar para la toma de requisitos:
1. ¿Quién sabe lo que hay que hacer?
Hace unos meses, trabajando para un cliente, acabé de Product Owner de un equipo supliendo a un compañero. El objetivo del equipo era actualizar visual y funcionalmente una aplicación existente. Había un trabajo realizado hace meses para estas modificaciones, por tanto, mi primera pregunta fue: ¿quién sabe lo que hay que hacer?
Es clave para un/a Product Owner localizar a las personas que son fuente de requisitos, peticiones, necesidades o personas en las que nos queremos enfocar. Identificar nuestras fuentes de requisitos es clave para mantener unas relaciones sanas con personas que podrían “afectar a nuestro equipo”.
Por tanto, hacer un listado de personas, entrevistas a cada una de ellas para conocer sus necesidades, y tenerlo presente en tu Product Backlog es clave. Es más, si puedes realizar algún taller de Inception o de Impact Map, donde puedas mapear esas necesidades con items del backlog, ayuda tanto a justificar el orden del backlog, como a gestionar expectativas con los interesados.
2. Involucra a todos en este ejercicio
Una vez, trabajando con un equipo de un gran banco, teníamos que demostrar en poco tiempo que éramos un equipo capaz de entregar más valor usando Scrum que con un método tradicional. Para ello, propusimos hacer un taller de Release Map, donde íbamos a dibujar los diferentes Sprints y el alcance esperado. La conversación inicial transcurrió así:
- Yo: ¿están en la sala todas las personas qué pueden decir sobre esto?
- Product Owner: sí, estamos todos, es más, si necesitamos retrasar la entrega podría hacerlo, pero no quiero
- Yo: perfecto, en ese caso, nos quedan dos Sprints para llegar a navidad, tenemos poco tiempo y no podemos dudar, tenemos que elegir muy bien qué es importante y qué es secundario
Cuando desarrollamos con una fecha encima, tenemos que elegir muy bien el orden en el que construir ya que, habrá que renunciar a aquello de poco valor. Ningún equipo es capaz de acertar con exactitud el trabajo que se hará, por tanto, hay que decidir qué parte podemos renunciar. Para poder tomar esta decisión, es clave que estén los interesados presentes, para que puedan ayudar a tomar la decisión.
Por muy empoderado que pueda estar un Product Owner, sí no deja participar a las personas que recibirán el trabajo, puede generar animadversión contra el equipo o los resultados.
3. Lean Inception para grandes trabajos
Una de las propuestas básicas de Scrum, y de Agile, es construir pequeñas partes rápidamente de manera que nuestro producto crezca iterativa e incrementalmente. Sin embargo, a veces, necesitamos entender muy bien un gran problema que queramos resolver sin extendernos en meses de análisis que bloquean nuestra capacidad de entregar.
Para encontrar el punto medio entre el análisis necesario y no esperar para entregar usamos la técnica de Lean Inception. El Lean Inception se utiliza con varios objetivos:
- Disponer de un Backlog primigenio
- Construir nuestra estrategia de producto
- Analizar métricas de producto que nos den visibilidad
- Visualizar una foto completa de todo lo que podríamos llegar a querer
- Gestionar expectativas sobre el alcance
Esta técnica la aplicamos con el Scrum Team y stakeholders invitados que, idealmente, serán clientes o usuarios. Con ello, nos permite un buen alineamiento antes de comenzar un gran desarrollo pero sin buscar una fecha comprometida cuando aún no hemos programado una sola línea de código.
4. Transparencia
Otro consejo clave para la toma de requisitos en Scrum es hacer transparente toda la información de la que dispongamos. Puede ocurrir que, hablando con diferentes interesados, veamos requisitos que se contraponen. Es clave juntar a las personas que difieran o, cómo decíamos en el punto anterior, realizar talleres tipo Inception donde todas las personas puedan participar de los requisitos.
Recordad que, la clave para un Product Owner es disponer de los requisitos lo más listo posibles para que, al hacerlos, tengamos muy pocas dudas. La diferencia entre Scrum y un Waterfall es que, en Scrum, no necesitamos detallar todo los requisitos del producto, solo aquellos que vayamos a abordar en el próximo Sprint.
En cada reunión muestra el Product Backlog, lanza dudas a personas sobre cualquier requisito futuro y escucha las observaciones. Con ese feedback, puedes decidir cambiar o ignorarlo, eso depende de lo que necesitemos. Precisamente, Scrum habla de que el Product Owner se asegure de que el Product Backlog es visible, claro y transparente.
5. Apóyate en el resto del Scrum Team
Como último consejo, debemos entender que, aunque el Product Owner sea el máximo responsable de la toma de requisitos, puede apoyarse en el resto del Scrum Team. Hay equipos que tienen especialistas en UX o en Análisis, puedes apoyarte en ellos. Además, apoyarte en el resto de developers es clave, un requisito puede estar muy claro funcionalmente hablando, pero puede ser un desastre a nivel técnico.
Una práctica, que viene heredada de las Historias de Usuario, es que el Product Owner se centra en describir el problema que queremos resolver y deja a los Developers la solución. Cuando los Developers participan, suelen asumir mucha más responsabilidad y, por tanto, mayor compromiso.
En Scrum, las responsabilidades están repartidas, ahora bien, un buen Scrum Team pone encima de la mesa todos los restos que tienen por delante y trabajan como un equipo.
Y tú, ¿qué consejos darías para tomar requisitos?
