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.
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.
