User stories y criterios de aceptación
Una user story no es un requisito escrito con una plantilla simpática. Es una promesa de conversación sobre un problema de alguien, y los criterios de aceptación son la parte de esa conversación que se queda por escrito para que nadie tenga que adivinar. En esta lección verás de dónde sale el formato, por qué tantas historias son malas aunque lo cumplan, cómo escribir criterios que cubran errores, permisos, datos, analítica, rendimiento y accesibilidad, y cómo se nota la diferencia entre un criterio débil y uno fuerte el día que QA bloquea un release.
Una user story describe en una frase una necesidad de alguien concreto y sirve para abrir una conversación; los criterios de aceptación son las condiciones observables que dicen cuándo está bien resuelta.
Importa porque la mayoría de retrasos y bugs de delivery nacen de algo que una persona daba por supuesto y otra no.
La idea clave: parte en vertical y escribe criterios que cubran también errores, permisos, datos, analítica, rendimiento y accesibilidad, de forma que cualquiera pueda comprobarlos igual.
- Reescribir historias mal planteadas (épicas, capas técnicas, sujetos difusos) como historias verticales con un usuario y un beneficio concretos.
- Redactar criterios de aceptación que cubran casos límite, estados de error, permisos, datos, analítica, rendimiento y accesibilidad.
- Auditar un conjunto de criterios, señalar los que no son comprobables o se contradicen y proponer la decisión que los resuelve.
Crea tu cuenta gratis para leer la lección entera
Crea una cuenta gratuita para acceder al contenido y guardar tu progreso.