Historias de usuario a partir de entrevistas: plantilla y criterios de aceptación
Identifica la necesidad en una entrevista, conserva la fuente y añade criterios verificables. Incluye un ejemplo y una plantilla.
Una historia de usuario describe el valor, no el botón
Una historia de usuario describe brevemente un resultado desde el punto de vista de quien usa el producto. Un formato habitual es «Como [rol], quiero [acción] para [beneficio]». Sirve para iniciar la conversación. Aún hay que definir los requisitos y verificar el resultado.
«Agreguen un botón verde» propone una solución. Para redactar la historia, averigua qué intenta hacer la persona y por qué el proceso actual se lo dificulta. Guarda la frase para poder verificar tu interpretación.
Como usuario, quiero un botón grande de exportación para que sea fácil de usar.
Como coordinador de proyecto, quiero compartir conclusiones seleccionadas de la reunión para que mi colega reciba solo los acuerdos que necesita.
Cómo redactar una historia a partir de una entrevista
Elige un caso concreto
Busca el último caso real. ¿Quién actuó, con qué material y qué buscaba? «Todo el mundo necesita informes» no basta para justificar una historia.
Anota las palabras exactas y su contexto
Guarda la marca de tiempo y unas frases cercanas. Distingue lo dicho de tu conclusión. Una situación excepcional no debe pasar por una tarea diaria.
Formula el rol, la acción y el beneficio
El rol debe explicar la situación. La acción debe ser observable. El beneficio aclara por qué la persona necesita realizarla.
Verifica el alcance
Una historia no debe abarcar desde el registro hasta un informe anual. Elige un resultado completo que pueda debatirse y verificarse por separado.
Añade criterios de aceptación
Escribe condiciones que permitan verificar el comportamiento. Incluye el caso principal y una excepción importante. Acuerda los criterios con el equipo antes de tratarlos como requisitos del cliente.
Vuelve a plantear las preguntas abiertas
Si no están claros los permisos, el volumen de datos o el formato, anota la pregunta. Evita rellenar la laguna con la solución más habitual.
De la frase de un coordinador a la ficha de historia
Después de la llamada envío al desarrollador solo sus tareas. Ahora las copio a mano y me preocupa incluir comentarios internos.
El ejemplo se refiere a un sistema ficticio de notas y no describe funciones de Transkribator. La necesidad es compartir una selección sin información adicional. Un botón de un color dado es solo una opción.
Historia. Como coordinador de proyecto, quiero reunir puntos elegidos de la reunión en un texto aparte para enviar al responsable solo los acuerdos que le afectan.
Criterios propuestos. Si se eligen tres puntos, el texto incluye esos tres y omite los demás. Antes de enviarlo, el coordinador ve el texto completo. Si no elige nada, el sistema explica que debe seleccionar puntos.
Pregunta abierta. ¿Debe incluir marcas de tiempo? La entrevista no lo aclara. Pregúntalo en la siguiente conversación antes de darlo por acordado.
La historia tiene una fuente, pero no sabemos si importa a la mayoría de los clientes. Una grabación muestra una experiencia. Decide la prioridad según otras pruebas, objetivos del producto y costo de implementación.
Cómo distinguir una historia de una lista de tareas técnicas
«Crear una tabla en la base de datos» o «añadir un manejador» son tareas técnicas. Pueden servir para implementar una historia, pero no explican el beneficio. Una frase bien construida tampoco prueba que el equipo entienda todos los límites.
Explica la historia a quien hace las pruebas sin nombrar un elemento de la interfaz. Si no sabes qué hace la persona antes y después, vuelve a la entrevista. Verifica los casos sin selección, sin permisos suficientes o tras un nuevo intento. Conserva solo las excepciones relevantes.
Ficha con fuente y preguntas abiertas
Título de la historia: Rol y situación de trabajo: Como [quién], quiero [acción] para [beneficio]. Fuente: entrevista / fecha / marca de tiempo: Palabras originales: Nuestra interpretación: Criterios de aceptación: 1. Con [condición], la persona puede [acción] y obtiene [resultado]. 2. Si [excepción importante], ocurre [comportamiento esperado]. Fuera del alcance: Qué falta aclarar: Quién confirmó la formulación y cuándo:
- El rol es concreto y el beneficio es claro.
- La cita se distingue de la decisión del equipo.
- Los criterios se pueden verificar observando.
- Las preguntas abiertas están identificadas.
Veamos los detalles
¿Siempre hay que escribir «Como… quiero… para…»?
No. Es una forma útil. Lo importante es entender quién es la persona, qué quiere hacer y por qué.
¿Cuántos criterios de aceptación hacen falta?
Los suficientes para el caso principal y las excepciones importantes. Los resultados independientes pueden requerir historias separadas.
¿Se puede escribir una historia a partir de una sola entrevista?
Se puede preparar una hipótesis con su fuente. No demuestra una necesidad de todo el segmento ni justifica por sí sola desarrollarla.