¿Cómo aplicar Scrum en la vida real?

Hace mucho, mucho tiempo, cuando las metodologías ágiles empezaban a ser una realidad en el mundo del desarrollo software en España, hablaba con una compañera de trabajo que me comentaba que tenía una pareja de amigos que aplicaban Scrum en su vida diaria.

Estos amigos son los dos ingenieros informáticos y aunque a día de hoy puede parecer algo trivial, en su momento nos impactó, sobre todo por el “proyecto” al que decidieron aplicar Scrum, la gestión de su propia boda. Desde entonces, cada vez que tengo que liderar un workshop a gente no iniciada en el mundo del desarrollo software, pongo este ejemplo donde creo se entiende a la perfección todo el proceso y lo que conlleva.

Pues bien, 8 años después de ese momento, me ha tocado gestionar mi propia boda y para dar ejemplo, ¡¡adivinad qué metodología ágil de desarrollo he decidido usar!!. El trabajo de mi pareja no está relacionado ni de lejos con el mundo de la tecnología o del desarrollo software, más bien lo opuesto totalmente, y es realmente curioso comprobar como alguien no metido en este mundo ha visto cómo se hacían los sprints, entendía el proceso y las iteraciones que íbamos haciendo, y sobre todo, comprobaba cómo los progresos y el desarrollo de nuestro propio producto era fluido y constante.

 

Product Backlog

Después de explicar a mi pareja cómo funcionaba Scrum, nos pusimos manos a la obra y lo primero que hicimos fue crear nuestro Product Backlog inicial, el cual estaría vivo durante el desarrollo de nuestro proyecto, usando la herramienta de brainstorming para producir un conjunto de ideas (User Stories).

¿Qué User Stories conseguimos definir al final del proceso tratándose de una ceremonia religiosa?

• Iglesia
• Fotógrafo
• Flores
• Traje de novio
• Vestido de novia
• Anillos
• Restaurante
• Música
• Regalos
• …

Definición de Roles y Criterios de Aceptación de las User Stories

Una vez definido el Product Backlog inicial, teníamos que dar forma a las funcionalidades de nuestro producto para saber en qué teníamos que trabajar exactamente para cada funcionalidad, pero para ello primero necesitábamos definir los roles que cada uno iba a tener y de esta forma diferenciar los flujos de trabajo.

• Product Owner = Prometida
• Scrum Master = Prometido
• Scrum Team = Prometida, prometido, padres, madres y hermanos

Ahora que ya sabíamos quién era quién, ya podía el Product Owner con la ayuda del equipo y del Scrum Master en definir las User Stories de nuestro Product Backlog incluyendo los criterios de aceptación para cada una de ellas.

A continuación, un par de ejemplos:

Como prometida de la boda, quiero que mi vestido de novia sea muy bonito de forma que quede a todos con la boca abierta.

Criterios de Aceptación:
•	El vestido tiene que costar menos de 2.000€ (IVA incluido)
•	Tiene que ser de color blanco
•	Tiene que ser un vestido de manga corta
•	Tiene que ser de palabra de honor
•	La cola del vestido debe tener al menos 65 cm de longitud
•	Se permite que los arreglos del vestido cuesten como mucho 150€

Como prometidos de la boda, quiero que el banquete sea espectacular de forma que todos los invitados salgan satisfechos de la comida.

Criterios de Aceptación:
•	El gasto medio por comensal no debe superar los 160€ (IVA incluido)
•	Tiene que tener canapés, entrante, primer plato, segundo plato, postre, café y chupito y bebida.
•	El vino de la comida tiene que ser un Vegasicilia del año 2003
•	El segundo plato tiene que ser solomillo de buey hecho en horno de leña

Priorización del Product Backlog

Una vez definido el Product Backlog inicial y especificados sus criterios de aceptación, teníamos que priorizar las User Stories y para ello, necesitábamos que el Product Owner fuera capaz de priorizar las funcionalidades:

• Iglesia
• Restaurante
• Vestido de novia
• Traje de novio
• Fotógrafo
• Flores
• Anillos
• Música
• Regalos
• …

 

Backlog Grooming

Ahora es responsabilidad de todo el equipo, Scrum Master e incluso del Product Owner de estimar, por orden de prioridad, las User Stories y de esta forma tener una visión de cuán difícil será completar esa funcionalidad en un sprint.

Para ello, utilizamos la sucesión de Fibonacci y votamos unas cuantas (no todas) funcionalidades para poder empezar a trabajar.

 

Sprint Planning y Sprint Backlog

Ya estábamos preparados para empezar a trabajar, así que decidimos realizar sprints de 3 semanas.

Hicimos un pequeño sprint planning en el que íbamos comprobando qué eventos/impedimentos/tareas…, es decir, el tiempo que teníamos para dedicar a este proyecto, teníamos durante ese período de tiempo para poder acometer más funcionalidades o no.

Una vez hecho el sprint planning, ya empezábamos a trabajar en nuestro sprint backlog durante ese período de tiempo, partiendo cada user story en tareas que pudiéramos acometer de forma individual.

 

Retrospectiva

Una vez finalizaba el sprint, hacíamos retrospectiva de esas 3 semanas y veíamos qué tal nos había ido todo: qué habíamos completado, qué no habíamos completado y por qué, qué impedimentos nos habíamos encontrado y sobre todo, cómo mejorar para el siguiente sprint.

 

Conclusión Personal

Decir que este proyecto tuvo una duración de unos 8-9 meses desde su inicio hasta su ejecución final, por lo que tuvimos unos 11 sprints en total.

La progresión del sprint #1 al sprint #11 fue excepcional. Mi pareja ya tenía el proceso tan interiorizado, que ya sabía perfectamente qué hacer y qué no hacer, por qué algo no había salido bien y por qué había salido mal, y tomándolo en serio, hemos conseguido que la gestión de la boda haya sido un éxito total.

Empezamos a sentir que la metodología estaba funcionando en el sprint #3-#4, donde verdaderamente comprobamos que la división en subtareas de las funcionalidades era realmente efectiva y que la metodología nos ayudaba a conseguir nuestros objetivos.

 

¿Funcionó mejor la gestión de una boda usando Scrum o no?. Bajo mi punto de vista, y sé de lo que hablo, sin lugar a dudas, pero eso os lo dejo a vosotros, por si alguien se anima también a gestionar su boda con Scrum.

 

Si te animas a probar, ¿te atreves a comentar tu experiencia con nosotros?

 

Enlaces relacionados:

Satisfacción del cliente con mejora continua ágil y digitalización

Bloques ágiles

Retrospectiva