Cómo escribir user stories que aporten contexto, no solo formato
Una user story con formato correcto pero sin contexto real es burocracia disfrazada de metodología. Esta guía explica qué hace útil a una user story y cómo escribirla para que el equipo pueda trabajar con ella.
El formato de user story está en todas partes: “Como [usuario], quiero [acción] para [beneficio].” Es tan omnipresente que se ha convertido en parte del ritual del trabajo ágil, con independencia de si aporta valor o no.
He revisado cientos de user stories a lo largo de los años. La mayoría tenían el formato correcto. La mayoría no tenían suficiente contexto para que el equipo de desarrollo pudiera tomar decisiones de implementación bien informadas.
Este es el problema real. No el formato.
Por qué el formato solo no es suficiente
Una user story sin contexto obliga al equipo de desarrollo a tomar decisiones que deberían haber tomado el PM y el diseño durante el discovery.
“Como usuario de ventas, quiero filtrar los contactos por estado para encontrar los que necesito llamar hoy.”
Eso tiene el formato correcto. Pero no dice:
- ¿Cuántos estados distintos existen? ¿Puede haber combinaciones de filtros?
- ¿Qué pasa cuando no hay contactos que cumplan los criterios del filtro?
- ¿El filtro persiste entre sesiones o se resetea cada vez?
- ¿Cuál es el volumen típico de contactos que maneja un usuario de ventas?
Sin esas respuestas, el equipo técnico va a tomar decisiones. Puede que acertadas. Puede que no. En cualquier caso, estarán tomando decisiones de producto sin el contexto que el PM debería haber provisto.
Los elementos que dan contexto real a una user story
El problema que se está resolviendo
Antes de la story en sí, una frase que describa el problema real del usuario. No la solución. El problema.
“Los responsables de ventas dedican hasta 20 minutos al inicio de cada jornada identificando qué contactos llamar, porque el sistema actual no permite filtrar por estado de seguimiento pendiente.”
Ese contexto cambia cómo el equipo aborda la implementación. Saben que el problema es de eficiencia operativa en una tarea diaria de alta frecuencia. Eso tiene implicaciones de diseño (el filtro tiene que ser rápido de usar, no solo correcto) y de implementación (el rendimiento importa porque se usa con frecuencia).
El usuario concreto
“Como usuario” no dice nada. Distintos tipos de usuario tienen contextos, necesidades y niveles de habilidad técnica diferentes.
“Como responsable de ventas que gestiona una cartera de 200+ contactos y trabaja principalmente desde desktop” es mucho más específico. Informa decisiones de diseño (la densidad de información en pantalla puede ser mayor, no está optimizando para móvil), de implementación (200+ contactos es un volumen que importa para rendimiento), y de criterios de aceptación (el filtro tiene que funcionar bien con volúmenes altos).
El contexto de uso
¿En qué momento del día ocurre esto? ¿Con qué frecuencia? ¿En qué dispositivo? ¿Con qué nivel de urgencia?
Esas preguntas parecen detalle. En realidad son las que determinan si la solución que se construye encaja con el uso real o con el uso imaginado.
Los casos extremos relevantes
Los casos extremos no son curiosidades técnicas. Son condiciones de uso real que hay que diseñar y que hay que estimar.
Qué pasa cuando no hay resultados. Qué pasa cuando hay demasiados resultados. Qué pasa si el usuario pierde la conexión a mitad de la operación. Qué pasa si los datos que necesita el filtro tardan en cargar.
Identificar esos casos en la story evita descubrirlos durante el desarrollo, cuando resolverlos tiene mayor coste.
Los criterios de aceptación que realmente ayudan
Los criterios de aceptación son la parte más importante y más ignorada de una user story. Su función es definir cuándo la historia está terminada de forma que sea verificable sin ambigüedad.
Formato Given-When-Then
El formato más útil para criterios de aceptación es Given-When-Then:
- Given (Dado que): el estado del sistema o el contexto del usuario antes de la acción
- When (Cuando): la acción que el usuario realiza
- Then (Entonces): el resultado esperado
Ejemplo:
Dado que el usuario tiene 150 contactos en el sistema y hay 23 con estado “pendiente de llamada”.
Cuando el usuario selecciona el filtro “pendiente de llamada” y aplica la selección.
Entonces el listado muestra exactamente los 23 contactos con ese estado, ordenados por fecha de último contacto de más antiguo a más reciente, y el sistema indica “23 contactos” en el encabezado del listado.
La diferencia entre criterio funcional y no funcional
Los criterios de aceptación pueden ser funcionales (qué hace el sistema) o no funcionales (cómo lo hace).
Los no funcionales suelen ignorarse en las stories pero son igualmente importantes: tiempo de respuesta, comportamiento con datos de producción (no de sandbox), compatibilidad con navegadores o dispositivos, accesibilidad.
Si hay criterios no funcionales relevantes para esta historia, tienen que estar explícitos. “El filtro tiene que aplicarse en menos de un segundo con el volumen de datos de producción” es un criterio de aceptación, no una recomendación de buenas prácticas.
La conversación que la story tiene que generar
Una user story bien escrita no es un documento cerrado. Es una invitación a la conversación.
Las preguntas que el equipo técnico hace después de leer la story son información valiosa: revelan los puntos ambiguos, los casos extremos no contemplados, las implicaciones técnicas que el PM no había visto.
Si el equipo lee la story y no hace ninguna pregunta, hay dos posibilidades: la story es perfectamente clara, o el equipo ha dejado de esperar claridad de las stories y está tomando decisiones de forma independiente.
La segunda opción es mucho más frecuente. Y es una señal de que el proceso de definición necesita trabajo.
Cuándo una story no está lista para el sprint
Una story no está lista para entrar en un sprint si:
- El problema del usuario no está articulado, solo la solución.
- No hay criterios de aceptación verificables.
- El equipo técnico tiene preguntas abiertas que no se pueden responder en el momento.
- El diseño no ha sido validado con usuarios o al menos con el equipo.
- Las dependencias con otras historias o sistemas no están identificadas.
Meter una story en el sprint sin esos elementos genera trabajo adicional durante el sprint: conversaciones de aclaración, decisiones de implementación tomadas sin contexto suficiente, cambios de alcance a mitad del desarrollo.
El refinamiento previo es más barato que el ajuste durante.
Las opiniones expresadas son personales y no representan la posición de ninguna organización.