Qué es una historia de usuario
En resumen: Una historia dice quién quiere algo, qué quiere y por qué, en una sola frase. No es una especificación: los detalles llegan en la conversación, y la confirmación dice cómo sabremos que está terminada. Una tarea del programador y una capa no son historias, porque nadie puede probarlas por sí solas.
Problema
La petición en una línea
En la lista de tareas del equipo hay una línea: «Códigos promocionales». El programador construye un campo de código que quita un 10 % de todo el pedido. El tester comprueba que se quita el 10 %. Todo pasa.
En el lanzamiento, marketing pregunta por qué el código funciona también en los productos rebajados. Contabilidad pregunta dónde puede ver cuánto descuento se ha dado este mes. Nadie hizo mal su parte. La línea «Códigos promocionales» nunca dijo para quién era ni por qué.
La idea
Quién, qué, por qué
Una historia de usuario expresa una necesidad en una frase con tres partes:
Como [rol] quiero [objetivo] para [beneficio].
Como cliente habitual quiero introducir un código promocional en el carrito para pagar menos por el pedido.
- El rol es la persona que tiene la necesidad. No «el usuario» en general, sino un cliente, un trabajador del almacén, una contadora. Son las partes interesadas del módulo anterior.
- El objetivo es lo que quiere hacer, con sus palabras, sin botones ni tablas.
- El beneficio es el porqué. Es la parte más valiosa, porque contra ella se valida la solución: si el campo de código funciona pero el cliente sigue sin pagar menos, la historia no está cumplida.
Una historia es un requisito pequeño, escrito para que empiece una conversación. En este curso decimos historia.
Más precisamente, para curiosos
La plantilla «Como …, quiero …, para …» se asocia a un equipo de la empresa británica Connextra hacia 2001, y se hizo conocida por el libro «User Stories Applied» (2004) de Mike Cohn. ISTQB CTFL v4.0.1 (sección 4.5, enfoques de prueba basados en la colaboración) da la misma plantilla: un rol, un objetivo y el valor de negocio para el rol.
La plantilla no es obligatoria. Algunos equipos escriben «Para …, como …, quiero …» para poner el beneficio primero. Lo que importa es que estén las tres partes.
Pruébalo
¿Historia o no?
La idea
Las tres C
Una frase no puede cargar con todo sobre los códigos promocionales. Y no debe. Ron Jeffries, uno de los creadores de Extreme Programming, describe una historia con tres palabras inglesas que empiezan por C. Se llaman las tres C:
- Tarjeta (card). La historia es lo bastante corta para caber en una tarjeta pequeña. La tarjeta no es el requisito; es un recordatorio de que hace falta una conversación.
- Conversación (conversation). Los detalles se trabajan en una conversación entre las personas que saben: el negocio, QA y el programador. Ahí surgen las preguntas «¿y los productos rebajados?» y «¿y si el código se usa dos veces?».
- Confirmación (confirmation). ¿Cómo sabremos que la historia está terminada? Con reglas y ejemplos concretos que se pueden comprobar. Se escriben antes del trabajo.
La historia de los códigos promocionales tenía tarjeta. No tenía conversación, así que tampoco tenía confirmación. Por eso «terminado» significaba «el programador paró».
Más precisamente, para curiosos
Jeffries describió las tres C en un artículo de 2001. ISTQB CTFL v4.0.1 las enumera en la sección sobre la escritura colaborativa de historias de usuario y vincula la confirmación con los criterios de aceptación. Los criterios son el tema de la lección «Criterios de aceptación» de este módulo.
La idea
Qué no es una historia
Tres cosas se confunden con más frecuencia con una historia:
- Una especificación. Una historia no lo enumera todo. Si la tarjeta se convierte en una página con todos los casos, la conversación no ocurrirá, y lo escrito seguirá incompleto. Los detalles se anotan después de la conversación, como reglas y ejemplos.
- Una tarea para el programador. «Añadir un campo de código a la página de pago» dice qué hacer, pero no para quién ni por qué. Las tareas están bien, pero vienen después de la historia, cuando el equipo decide cómo construirla.
- Una capa del sistema. «El backend de los códigos promocionales» o «la pantalla del carrito» son partes de la solución. Nadie puede probarlas por sí solas y decir «sí, esto es lo que quería».
Y una más: «Como sistema quiero…» no es una historia. El sistema no tiene necesidades. Detrás de cada «como sistema» hay una persona que todavía no hemos encontrado.
Pruébalo
¿Qué «para» es un beneficio?
En cada pregunta, elige el final de la historia que expresa el beneficio real.
La idea
Por qué importa el beneficio
El beneficio hace dos cosas.
Primero, contra él se valida la historia. «Para poder decidir si añado algo más para llegar a 50,00 €» dice que no basta con mostrar el envío después del pago. Tiene que verse en el carrito, mientras el cliente todavía elige.
Segundo, abre mejores soluciones. La contadora pide un botón de Excel. El beneficio es «para conciliar con el banco». Quizá la mejor solución sea un informe ya hecho que llegue solo. Es el mismo hábito que en la lección sobre obtención de requisitos: la necesidad detrás de la solución pedida.
Si no puedes escribir el beneficio, es una señal. O no sabes por qué se construye la historia, o no hace falta. En ambos casos el siguiente paso es una pregunta, no trabajo.
Ejercicio
De la petición a la historia
1. ¿Qué historia expresa la necesidad? Tres peticiones de partes interesadas, cada una con tres intentos de escribirla.
Test