¿Cómo se crean los requisitos iniciales en agilidad? Inception Deck

Artículo "¿Cómo se crean los requisitos iniciales en agilidad? Inception Deck" de Ángela Plaza Lora en la Revista Stakeholders.news

Cuando doy formaciones de Scrum y Agile a veces me pasa que nos centramos en lo básicos: los orígenes de la agilidad, el manifiesto, roles y ceremonias en Scrum…etc. y dejamos fueras temas tan importantes como el que quiero tratar hoy en este artículo. Más de una vez me han preguntado: ¿qué marco de trabajo/técnica se encarga de definir qué cosas queremos construir? ¿qué marco o técnica se focaliza en la construcción inicial del backlog? Sigue leyendo que te lo cuento.

Una de las herramientas más útiles y que yo más uso para crear ese backlog o listado inicial de necesidades es lo que se conoce como “Inception Deck”. Esta dinámica la conocí de manos de Jonathan Rasmusson en su libro “The Agile Samurai: How Agile Masters Deliver Great Software” y como te decía, es una herramienta que recomiendo encarecidamente usar para este ejercicio.

El “Inception deck” es, en su origen, un taller que puede durar desde un par de días a un par de semanas, y en el que a través de una serie de preguntas y ejercicios podremos ir descubriendo sobre qué va el proyecto, sobre qué no va y cuánto nos puede llevar entregar la solución. En definitiva, el objetivo de este “Inception deck” es cubrir esa parte inicial de definición y toma de requisitos que normalmente ocurre al iniciar un proyecto y que echamos de menos en marcos de trabajo como Scrum donde no se define qué ni cómo hay que hacerlo y simplemente se focaliza en el desarrollo de la solución/producto per se.

Lo primero que nos dice Rasmusson sobre este “Inception deck” es que es de vital importancia tener a las personas adecuadas para este ejercicio. Para él, las personas adecuadas son aquellas que pueden contribuir de algún modo a una ejecución efectiva de lo que estamos construyendo. Eso quiere decir que, de tener un equipo de Scrum, todos los roles: desarrolladores, scrum master y product Owner, así cómo stakeholders, managers etc. que puedan intervenir directa o indirectamente, deberían estar invitados a estas sesiones.

Otra de las cosas que nos cuenta Rasmusson sobre el “Inception deck” es que, al igual que el Product Backlog, está vivo y evoluciona con el tiempo y con la solución/producto. Por lo que deberíamos realizar este ejercicio al menos, en mi opinión y por mi experiencia, una vez al año. Rasmusson, por su parte, es más estricto y aconseja que se haga cada seis meses.

Y lo que más me gusta de este ejercicio es que rezuma agilidad por todos lados y nos advierte que el listado de preguntas es solo una guía pero que el equipo la puede adaptar, modificar o añadir cualquier otra pregunta o ejercicio que considere necesario para llegar al objetivo final. ¿No es maravilloso? De nuevo lo prescriptivo queda a un lado, lo importante entregar con valor, y para ello, hay que adaptarse a las circunstancias de cada equipo.

Una vez tenemos a la gente correcta y un objetivo claro es hora de comenzar con las preguntas y ejercicios de este “Inception deck”

  1. ¿Por qué estamos aquí? La idea de esta pregunta es contestar por qué estamos donde estamos, quiénes son nuestros clientes y por qué estamos construyendo este producto/servicio
  2. Elevator pitch: este ejercicio se basa en crear un discurso de 30 segundos en el que seamos capaces de vender nuestro producto, resaltando sus cualidades
  3. Diseña la caja de tu producto: ¿qué slogan tendría nuestro producto si lo anunciásemos en una revista? ¿Qué aspecto tendría de estar en un lineal de un supermercado?
  4. La lista de noes: tenemos claro lo que queremos hacer en nuestro proyecto, pero… ¿sabemos lo que no queremos hacer?
  5. Conoce a tus vecinos: esto es pura identificación de stakeholders. Este ejercicio ayuda al equipo a identificar qué personas o grupos se pueden ver impactados por el desarrollo de nuestra solución/producto
  6. Muestra la solución: este ejercicio está muy orientado al desarrollo de soluciones software y básicamente busca que el equipo defina la arquitectura de la solución
  7. ¿Qué nos mantiene despiertos por la noche? Riesgos, dependencias y más riesgos ¿qué es lo que nos preocupa a nivel proyecto y puede hacer peligrar el éxito de este?
  8. Dimensiónalo: los productos/soluciones tienen una larga vida, pero si hablamos a nivel proyecto, ¿va a ser un proyecto de tres meses? ¿de seis? ¿de un año?
  9. Sé claro en lo que se va a dar: ¿qué es lo más importante para el equipo a nivel proyecto? ¿es la calidad? ¿tenemos restricciones de tiempo que cumplir? ¿o de presupuesto?
  10. Muestra cuánto nos va a llevar: esta pregunta pretende identificar cuánto va a costar el desarrollo de la solución/producto, cuántas personas tendremos en el equipo…etc. es decir, con esta pregunta, pretendemos cubrir la parte más financiera de la iniciativa.

Tras contestar todas estas preguntas y realizar todos los ejercicios, el siguiente paso es reunir a product owner y desarrolladores y que se pongan a identificar qué quiere el usuario, con el objetivo de crear esa lista de requisitos iniciales denominada comúnmente como Product Backlog.

Si no has usado anteriormente “Inception deck” te recomiendo que los uses para crear tus backlogs. Verás que la motivación del equipo al completo crece al verse partícipe y estar involucrado desde el primer momento y el desperdicio se reduce gracias a poner el foco en contestar a las preguntas importantes. ¿Te animas a probarlo?

Revista Stakeholders - Primera Temporada - Transformación Agile con Angela Plaza

Ángela Plaza Lora

Manager y Scrum Master en una de las Consultoras más importantes del país. Tuvo la suerte de nacer en Sevilla y de poder desarrollar su carrera en esa ciudad. En sus ratos libres podrás encontrarla disfrutando de su pequeña, paseando por las calles de su ciudad leyendo un buen libro.  

Todo lo que un Directivo debe saber...

Ha llegado la hora de formar a la Alta Dirección

Sesiones Directivas en Directo y en Remoto sobre todos aquellos aspectos que debe conocer la Alta Dirección sobre Gobierno y Gestión Organizacional.