Contando historias con “Rory’s Story Cubes”

Conocí los Story Cubes en un meetup de AgileBarcelona, donde varias personas que habían participado de la conferencia play4Agile, compartieron los juegos aprendidos.

Los Story Cubes fue el juego que más me gusto en general, más que nada por su sencillez y por la gran cantidad de aplicaciones que pueden tener. Fomentan la creatividad no solo a la hora de usarlos, sino también al pensar en posibles usos que les podamos dar. ¡Así que me los compré y empecé a usarlos!

Por si no los conoces todavía, estos son los Story Cubes. Y el juego consiste en tirar los dados y contar una historia en base a los símbolos que salgan.

rscgame_2x

 

Desde que los tengo, estas son las tres situaciones distintas donde los he utilizado…

Como rompe-hielos de una sesión, para que los participantes estén más distendidos y más predisponerlos a pensar fuera de sus estructuras.

Al inicio de una Retrospectiva, para resumir las sensaciones del sprint anterior. Usando los dados en este momento puedes lograr que salgan cosas que quizás de otra forma no saldrían, ya que al tener que improvisar una historia en base a los símbolos que salieron, no tienes tiempo de pensar mucho lo que dices y terminas diciendo lo que realmente sientes. Y al mismo tiempo inicias la retrospectiva de una forma lúdica y haciendo participar a todos muy activamente. Esto ayuda a la participación durante el resto de la retrospectiva.

Empezando un nuevo proyecto. En esta ocasión los usamos de dos formas distintas, pero ambas con el objetivo de trabajar la motivación por el nuevo proyecto y cohesionar al equipo para afrontar el reto.

Primero cada miembro del equipo contó una historia de cómo se sentía respecto al nuevo proyecto y al equipo. Aquí salieron las cosas que los motivaban (poder aprender cosas nuevas, empezar algo de cero, lo desafiante del proyecto) y algunos también algunos temores o inseguridades.

Luego los utilizamos para hacer una “futurespective” (mirada hacia el futuro), donde nos imaginábamos que nos entrevistaban por el gran éxito de nuestro proyecto. Para esta parte cada uno tiró un dado y contó una parte de la historia que entre todos creamos. Aquí salieron varios temas importantes que identificamos como claves para el éxito del proyecto y además la sensación de equipo en ese momento era genial.

Como pueden ver, los dados dan muchas posibilidades de uso. Leyendo un poco he visto que se utilizan para facilitar retrospectivas enteras, para mejorar la creación de historias de usuario, para la creación de ideas y fomentar la creatividad a la hora de resolver problemas, etc.

Siempre me gusta entender un poco el porqué de las cosas y los story cubes no son una excepción. Por eso en el próximo post voy a escribir sobre las razones por las que este tipo de juegos ayudan y como impactan en nuestra forma de pensar.

Si alguna vez usaste los Story Cubes déjame un comentario contando tu experiencia. Y si nunca los usaste pero se te ocurren otras formas de usarlos también!

Anuncios

¿Cómo escribir User Stories?

Como ya dije en el post “Que son las User Stories”, lo importante es que una historia de usuario (si, voy a intentar llamarlas por su nombre en castellano J ) permita entender de una manera simple lo que el usuario quiere conseguir. Cuando una historia se crea, generalmente solo tiene esta descripción (la primera ‘C’ –Card), ya que luego, en el momento que sea prioritaria, será refinada y se le agregaran más detalles o incluso se dividirá en varias historias de usuario más pequeñas.

Entonces para escribir buenas historias de usuario es importante buscar la mejor forma de escribir esta descripción, ya que es la que nos recordará lo que el usuario necesita y nos ayudará a hacer las preguntas correctas a la hora de entenderlas mejor. La forma más extendida de escribirlas es utilizando el formato “As a [who/role] I want [what/goal] So that [why/benefit]” o “Como [quien/rol] Quiero [que/acción] Para [razón/beneficio]”. Si desglosamos un poco esto para entender realmente por qué se utiliza esta forma de escribir las historias luego nos será más fácil escribirlas correctamente e incluso adaptarla a nuestro contexto. Sigue leyendo

AOS 2016 – Charlas interesantes

Continuando con el post anterior  hago un pequeño resumen de las charlar o sesiones de las que participe para terminar de compartir mi experiencia en el AOS 2016.

juegos

Facilitación y coaching

Juegos y actividades: La mañana empezó con Israel de Thinking With You compartiendo juegos y actividades grupales que son una gran herramienta para un coach o scrum master a la hora de facilitar una sesión de trabajo. Hicimos algunos juegos para romper el hilo, que son buenos para preparar a la gente a que esté predispuesta a participar y en caso de que trabajemos con grupos grandes pueden ayudar a que se conozcan entre ellos. Para terminar hicimos un juego para potenciar la mejora a través de la experimentación llamado “try or die”. Para el que no lo conozca le recomiendo que lo juegue alguna vez! Sigue leyendo

AOS 2016 – Una gran experiencia

La semana pasada tuve la suerte de participar del Agile Open Space (AOS) en Santiago de Compostela. Era mi primer open space y como las semanas anteriores estuve muy ocupado no tuve tiempo ni de pensar en el evento (con que objetivo y expectativas iba, sí proponer alguna charla o no, etc.) Pero la verdad que haber ido así tan “a lo que venga” fue una muy buena forma de participar. A veces cuando menos pensas las cosas más disfrutas de la experiencia. Tan buena fue la experiencia que al AOS 2017 en Segovia voy seguro!

Por si es la primera vez que escuchas hablar de “Open Space”, es una forma de organizar eventos y reuniones donde los mismos participantes son los que definen la agenda, para así crear varias sesiones en paralelo que traten distintos asuntos alrededor de un tema central. En el caso del AOS el tema central claramente era “Agile” (agilismo, métodos ágiles o el término que más te guste, yo nunca me decido por uno). Tanto es así que antes de empezar el open space propiamente dicho hicimos una actividad donde en 2 minutos todos los asistentes llegábamos a un consenso para describir qué es “agile” en dos palabras. Éramos más de cien personas así que los dos minutos no fueron suficientes para llegar a solo dos palabras, pero estuvimos cerca! Cultura y colaboración fueron las palabras elegidas por muchos. Sigue leyendo

Qué son las User Stories

Ahora que ya entendemos porque existen y cuál es el objetivo que buscan, veamos qué son exactamente estas tan famosas User Stories.

Se dice que las User Stories son una “promesa de una futura conversación”. Esto es porque en un principio cuando se crean suelen ser una simple frase o breve descripción de una funcionalidad que aporta valor al usuario o al negocio y que si no es prioritaria en ese momento no se entra en más detalle. Es por esto que queda en el backlog como un recordatorio de un requerimiento, para en el futuro trabajar sobre ella entre el Product Owner (PO) y el equipo (PO en el contexto Scrum o responsable de producto y/o definición de necesidades y prioridades como rol más genérico). Esto nos permite enfocarnos en lo que hoy es importante sin miedo a olvidarnos de algo en el futuro.

Una User Story se compone de tres partes. Tarjeta, Conversación y Confirmación (CCC por sus siglas en inglés). Sigue leyendo

Por qué las User Stories en un contexto ágil

Para entender el por qué de las User Stories creo que es bueno ir un paso atrás e intentar entender que en el desarrollo de software ágil (contexto en el que las User Stories han nacido y en el que viven actualmente) se intenta cambiar (entre otras cosas) hacia una forma de desarrollo que se adapte a las necesidades cambiantes del cliente o producto. Esto es un punto muy importante y que considerando la velocidad a la que cambian actualmente las tecnologías, cada vez toma más protagonismo. Un estudio1 realizado hace pocos años indica que entre 1980 y 1990 la mitad de los requerimientos de un sistema  dejaban de ser válidos después de diez años, que en el 2000 ese tiempo de vida de la mitad de los requerimientos pasó a ser de unos dos años y actualmente se estima que ese tiempo es de seis meses. Esto quiere decir que si estamos escribiendo un requerimiento que va a ser desarrollado en unos meses, tenemos una probabilidad muy alta de que incluso antes de empezar a desarrollarlo el requerimiento ya no sea válido y haya que cambiarlo.

Lo anterior está directamente relacionado con el valor del manifestó ágil de Respuesta ante el cambio, pero para tener una buena captura de requerimientos ágil también necesitamos un método que se adapte a los valores que ponen el foco en Individuos e interacciones, Software funcionando y Colaboración con el cliente. Sigue leyendo