Ir al contenido principal

Mi primera sesión de sprint planning en Scrum

Cada día iba descubriendo algo nuevo de Scrum, por un lado el aire que se respiraba en la oficina bajo Scrum parecía menos tensionado o estresado que en otras oficinas sin metodologías ágiles, lo cual era bastante bueno, sin embargo cuando el sprint llegaba a su fi, los días anteriores, es cierto que algunas veces se respiraba más agobio, pero nada preocupante.

El trabajo se organizaba en periodos bi-semanales, llamados sprint. Cada sprint arracanba y terminaba el mismo día de la semana, cada dos semanas. ¿En qué se trabajaba en un sprint? Para contestar a esta pregunta hay que hablar de lo que es un sprint planning, en siguientes artículos hablaré más detenidamente sobre esta sesión, ahora contaré mis impresiones de lo que viví.

Nos reunimos todos, desarrolladores, QAs, y el producto owner. Este último empezó repasando el sprint actual, que se estaba a punto de cerrar, para ver si se había terminado todo el trabajo, o quedaba algo por finiquitar. Lo que no se había podido terminar por alguna razón se incluiría en el nuevo sprint. Por otro lado repasamos el backlog (pila de todos los tickets con las historias de usuario), nuestro product owner (PO) tenía las historias de usuario preparadas, priorizadas y estimadas por nosotros (equipo de desarollo), cosa que habíamos hecho en sesiones anteriores de refinamiento.

El PO empezaba incluyendo user stories desde el backlog (desde arriba) al borrador de lo que sería el sprint, hasta llegar a una cantidad adecuada para el equipo. Se volvía a repasar cada ticket (elemento), así lo recordabamos, repasabamos el motivo por el que era importante para el usuario, y comentabamos de nuevo las posibles dificultades o planteamiento técnico. Finalmente, el PO nos preguntaba si nos comprometíamos con dicha configuración del sprint, y eramos nosotros, el equipo de desarrollo (programadores y QAs) quienes aceptábamos o negociábamos incluir o eliminar alguna historia de usuario, dependiendo de la capacidad que tendriamos durante las próximas dos semanas.

Una vez aceptado el borrador de sprint, le poníamos un nombre al sprint. Esta era la parte más divertida, siempre buscábamos un nombre gracioso de acuerdo a la configuración del sprint o bien a algo importante reciente que hubiera pasado en nuestro grupo de trabajo, o fuera a pasar.

Habeus sprint, se nos planteban dos semanas apasionantes de desarrollo y más refinamiento (para los siguientes sprints). El primer paso, nueva reunión corta para ver quién hace qué, y como nos auto-organizamos.

Comentarios

Entradas populares de este blog

Primer contacto con el agilismo

Al entrar a trabajar en una empresa donde imperaba ser ágil, las metodologías con mismo nombre, y el framework de Scrum, me chocó todo un poco al principio, y pasados los primeros días el choque fue mayor aun. Es cierto que la oficina llevaba poco tiempo en funcionamiento en nuestra ciudad, eramos muy pocos, y toda la oficina estaba inmersa en conocer los productos, el código, y empezar a ser mínimamente productivos, es decir, en aquel entonces no había grupos de trabajo a pleno rendimiento, ni eran sabios en la parte funcional donde se implementaba. Dadas estas circunstancias, y a la metodología ágil de Scrum, la forma de trabajo fue muy distinta a lo que yo estaba acostumbrado, no era mi zona de confort. Por un lado teníamos unas sesiones mañaneras llamadas "stand up" o "dailies", donde había que decir que se había hecho el día anterior, que se iba hacer en el día presente y si habías tenido algún bloqueo o impedimento. Teóricamente estas sesiones no debían pasar

Mi primer toma de contacto con un refinamiento de Scrum

 Como he comentado en un artículo anterior, he trabajado durante muchos años en empresas que no usaban la metodología ágil. Los requerimientos venian dados por un analista (en el mejor de los casos, otras veces venía directamente de consultores con poco o ningún bagaje en tecnologías de la información); y normalmente eran unos documentos extensos, muy detallados, con gráficos, ... incluso notas o indicaciones técnicas. A mi personalmente me gustaban esos documentos, todo quedaba muy detallado, claro y conciso, pero esto mismo produce su gran debilidad, que hablaré más detenidamente de ello en otro artículo. Estando acostumbrado a trabajar con dichos documentos, me sorprendió bastante, primero con desconfianza y con el paso del tiempo con agrado, mis primeras sesiones de refinaminamiento, o también conocidas como refinements . El equipo de desarrollo al completo más el product owner (PO), nos reuníamos una o un par de veces semanalmente para hablar de los requerimientos. A diferencia de

Antes de ser ágil

Hace unos cinco años y medio, empecé a trabajar en una nueva empresa internacional, donde la sede principal está situada en otro país, la empresa tenía negocio en dicho país y en otro más, y además abrieron la sede en España donde yo me uní. En ese momento yo tenía catorce años de experiencia en empresas de IT, principalmente como desarrollador de software en distintos lenguajes y tecnologías, en escritorio y web, pero también había realizado labores de analísta y coordinador de equipos de trabajo. Cuando digo que que trabajé en rol de analísta, no me refiero al gran demandado y polivalente "analísta-programador", que sí, que también tuve ese título en otra empresa, sino a meramente "analísta". ¿Qué hacía como analísta? Básicamente me llegaban solicitudes de requisitos de compañeros consultores, los cuales trataban directamente con el cliente final. Algunos de estos consultores tenían el clásico corte de comercial, otros, en cambio, sí tenían background en tecnologí