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

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

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)