Historias de usuario: en búsqueda del entendimiento compartido

¿Cómo alinearnos mejor con nuestros usuarios? ¿Cómo entender sus necesidades cuando no comprendemos la forma en que escriben los requerimientos? Pues bien, ahí está precisamente el quid del asunto. El problema principal no es cómo escribimos o cómo redactamos un texto: es de qué manera interactuamos.

PNG image-90B34C7FA176-1

La importancia de la comunicación cara a cara

Cuando hablamos de historias de usuario, nos centramos en la conversación. Partimos de una necesidad que tiene nuestro usuario y a partir de ahí hablamos en torno a entender muy bien esa necesidad y el para qué (los beneficios que esperamos obtener).  La conversación es lo que permite que haya un entendimiento compartido, que pasemos de decir “supongo que esto es a lo que se refería” a decir “entiendo para qué lo necesitas“.

Origen

Las historias de usuario, o user stories, tienen su origen en el trabajo de Kent Beck, a finales de los 90’s. Él notó (supongo que no fue el único…), que diferentes personas leyendo el mismo documento, pueden interpretarlo de maneras completamente diferentes. Entonces incluyó dentro de “Extreme Programming” el término “historia de usuario” para definir algo que un usuario quiere hacer dentro de un sistema, y de lo que se hablará con más detalle antes de construirlo.

Las tres C

PNG image-00F72E0BD373-1

Partiendo de que buscamos el entendimiento compartido entre los que tienen una necesidad y los que saben cómo resolverla, entonces ¿cómo seguimos? Ron Jeffries encontró cómo resumir el proceso en tres simples C:

Card (Tarjeta)

Una oración que resume la necesidad y se escribe en una tarjeta. Es frecuentemente utilizado el formato rol-necesidad-beneficio (o formato Connextra). No es obligatorio usarlo, pero es una buena guía para empezar. Cada necesidad del usuario se escribe en una tarjeta (de modo que se convierta en una promesa de conversación). IMPORTANTE: son escritas desde el punto de vista del usuario.

Formato rol-necesidad-beneficio

Como [tipo de usuario] -> quién
quiero [necesidad] -> qué
para [beneficio esperado] -> para qué

¿Cómo se vería esta información con una historia real? Veamos:

Ejemplo:  Retirar dinero
Como cliente del banco,
quiero retirar dinero de mi cuenta
para hacer pagos en efectivo”

Con estas tres simples líneas conoceremos: el quién (lo que nos permitirá ubicarnos dentro de un contexto de uso), el qué (cuál es el problema a resolver) y el para qué (el valor que esperamos obtener una vez construida la historia, y que será fundamental a la hora de priorizar).

Conversation (Conversación)

La conversación es la comunicación cara a cara (¡no es un título en un documento!). Es el momento en que se juntan las personas que conocen la necesidad con quienes conocen cómo solucionarla, para hablar en torno a ello. A partir de preguntas y respuestas, se busca el entendimiento compartido del problema que se quiere resolver. Aquí es recomendable usar todos los recursos que estén a nuestro alcance para validar nuestro entendimiento (hacer prototipos, usar facilitación gráfica, etc.).

Ejemplo: Retirar dinero
“-¿Existe algún máximo de dinero a retirar por transacción?
– Sí, $200 por transacción, y $1.000 por día.
– Si el usuario tiene menos dinero del que quiere retirar, ¿qué mensaje se le muestra?
– Podría ser “Señor usuario, los fondos son insuficientes. Por favor intente con un valor menor o igual a xxx”.
– ¿La interfaz de usuario podría mostrar la información de esta manera?
<<mostrar prototipo>>
– Sí, y agregaría…
– ¿Qué pasa si el cajero no tiene dinero suficiente?
– En ese caso…”.

Confirmation (Confirmación)

La Confirmación es el acuerdo en torno a lo que vamos a construir. Es lo que nos permitirá saber si terminamos de construirlo o no, y si cumplimos con lo que se esperaba. En este punto podemos plantear escenarios y la manera como el sistema se comportará en cada uno de ellos. Lo anterior es lo que llamamos “criterios de aceptación“. Una historia de usuario puede tener uno o muchos criterios de aceptación.

Ejemplo: “Retirar dinero”
“- Dado que tengo $400 en mi cuenta
cuando voy a retirar $100
entonces mis saldo queda en $300 y el sistema me entrega $100.”

¿Y después?

Las Historias de Usuario serán el insumo para construir de manera incremental nuestro producto. Deben ser pequeñas, de modo que puedan terminarse, de punta a punta, dentro de una iteración de trabajo. Un buen resumen de cómo dividir las historias de usuario, se encuentra en este genial mapa de Agile for All.

Referencias

  • Cohn, M. (2018). User Stories and User Story Examples by Mike Cohn. [online] Mountain Goat Software. Disponible en: https://www.mountaingoatsoftware.com/agile/user-stories
  • Patton, J. (2014). User story mapping. Beijing: O’Reilly. (disponible en Amazon)
  • Cohn, M. (2013). User stories applied: for agile software development. Boston: Addison-Wesley. (disponible en Amazon)

Compartiendo experiencias: Una retrospectiva (1)

Me gusta mucho encontrar formas diferentes de trabajar las retrospectivas con los equipos, de modo que la búsqueda de la mejora continua capture el interés de las personas que participan en ella. Hoy quiero compartir una de las retros que hice hace unos días, y que posiblemente servirá de inspiración para alguien que también esté buscando ideas…

Icebreaker: Los súper héroes (15 minutos)

Para que una retro sea verdaderamente productiva debemos tratar, como facilitadores, que los asistentes se sientan cómodos de brindar sus opiniones, creando una atmósfera de comunicación fluida. Esto lo podemos lograr con los “icebreakers”, actividades que, como su nombre lo indica, buscan romper el hielo. En la retro de la cual hablo hoy rompimos el hielo con una actividad conocida como Los súper héroes, que también permite que el equipo se conozca mejor.

La dinámica consiste en que a cada miembro del equipo se le da una hoja de papel y un marcador para que haga lo siguiente:

  • Dibujo de cómo se visualiza como súper héroe
  • Nombre de súper héroe: Ideal que sea un nombre creativo/divertido.
  • Súperpoderes: ¿Cuáles son mis súper poderes, de cara al equipo?
  • Debilidades: ¿Cuáles son mis debilidades, de cara al equipo?
  • Archienemigo: Esa cosa o esas cosas que no puedo soportar (tratar de pensarlo desde el contexto laboral).

Yo lo que hago es que al momento de explicar la actividad tengo una guía visual de lo que deben hacer, que luego les pongo en un lugar visible.

Facilitación gráfica_14

Al terminar, cada persona presentó su Súper Héroe a los demás miembros del equipo, y pegamos los dibujos en una ventana. Han pasado varios días y los dibujos aún están adornando su lugar de trabajo 🙂

20160126_115732 (1)

* Ésta dinámica la complementé a partir de una que encontré en Retromat 

Objetivo de la retro

Es importante variar las retrospectivas que se hacen con los equipos para que las reuniones sean más dinámicas, pero no es algo que deba hacerse deportivamente. Tenemos que contar con un criterio claro, basado en las necesidades del equipo y en si, como coaches, queremos apoyarlos en un tema en particular que el equipo esté necesitando.

Por sugerencias previas de algunos miembros del equipo, decidimos que el objetivo de esta retro fuera el cambio, lo que coincidía además con lo que varios habían señalado como debilidades en la actividad de súper héroes.
Empecé planteándoles tres preguntas, que había preparado previamente usando la herramienta Pollev, en la que pueden votar y los resultados se ven en tiempo real, cambiando los porcentajes a medida que la gente vota (cosa que logró conectarlos bastante con la reunión, hasta querían que fueran más preguntas…).

 Pregunta 1: Entre las siguientes dos opciones, dirías que el equipo esPregunta 1: Entre las siguientes dos opciones, dirías que el equipo es:

Pregunta 2: Con respecto a la forma como enfrentamos los nuevos retos COMO EQUIPO, dirías:
20160126_105733
Pregunta 3: Al momento de buscar alternativas de solución a un problema:
20160126_105937
A partir de ahí empezamos a hacer el análisis de por qué creían, como equipo, que eran temerosos ante el cambio. Luego del análisis obtuvimos varios post-its por los cuales votaron, siendo dos los más votados:  “Nos vamos por lo fácil y conocido” y “Presión de tiempo para mantener la operación”. Luego les hablé un poco de las zonas de control, influencia y preocupación para ver donde ubicarían estos dos ítems, concluyendo que el hecho de irse por lo conocido era algo sobre lo que se podía trabajar como equipo.

CIERRE

Hablamos un rato sobre posibles soluciones a los problemas encontrados y luego les pedí que escribieran en un postit cuál iba a ser su próximo pequeño paso en dirección a ser más abiertos al cambio. Construyeron con esto un plan de mejora (con responsables y fechas), pensando en que fueran accionables concretos y no simple “politiquería” o palabras bonitas.
Y al final, la encuesta de la retro!! 💃
Esta última pregunta la podemos hacer votando con las manos (dedo pulgar hacia arriba, al medio o hacia abajo), o puede ser una pregunta en Pollev. Sea como sea que la hagamos, es una buena práctica preguntar la opinión de los asistentes al final de nuestras reuniones, para identificar oportunidades de mejora que nos permitan aprovechar mejor estos espacios con la gente.
20160126_115722