Atlasingeniería

Producto y metodologías ágilesJuniorTema 3Junior

Escribir lo que hay que construir sin escribir cómo

Una historia de usuario no es un ticket con formato bonito: es un recordatorio de una conversación pendiente. Lo que la hace útil no es la plantilla «como usuario quiero», son los criterios de aceptación.

«Como usuario quiero poder exportar los datos para poder analizarlos.» Está bien escrita según la plantilla, y no alcanza para construir nada: ¿qué datos, en qué formato, con qué filtros, qué pasa con diez mil filas, quién puede exportar?

La plantilla es lo menos importante. Una historia sirve cuando alguien puede construirla sin volver a preguntar, y cuando hay una forma objetiva de decir si está terminada. Eso último son los criterios de aceptación, que es la parte que casi siempre falta.

Los criterios de aceptación

Son la lista de condiciones que tienen que cumplirse para que la historia esté terminada. Se escriben antes de construir, no después, y sirven para tres cosas a la vez: acordar el alcance, guiar los tests y evitar la discusión de si estaba incluido o no.

Historia sin criteriosCon criterios
Exportar los datos a ExcelSe exporta la tabla visible con los filtros aplicados · Incluye encabezados · Hasta 10.000 filas; más que eso avisa y ofrece filtrar · Sólo pueden exportar los usuarios con rol de analista · El archivo se llama con la fecha del día
Recuperar la contraseñaCon un mail registrado llega un enlace que vence en una hora · Con uno no registrado se muestra el mismo mensaje, para no revelar quién está registrado · El enlace sirve una sola vez · Al cambiarla se cierran las otras sesiones
La columna derecha se escribe en diez minutos de conversación y ahorra tres idas y vueltas durante el desarrollo.

La plantilla

Plantilla

Historia de usuario

Título

Una frase con el resultado desde el punto de vista de quien lo usa. Por ejemplo: exportar el listado filtrado a una planilla.

Si el título nombra una solución técnica —«agregar endpoint de exportación»— probablemente sea una tarea, no una historia.

Quién, qué y para qué

Quién lo necesita, qué quiere hacer y con qué fin. El «para qué» es el que más se saltea y el que permite proponer alternativas mejores.

Cuando el para qué está claro, el equipo puede sugerir formas más baratas de lograr lo mismo.

Criterios de aceptación

La lista de condiciones verificables. Incluí al menos un caso borde y un caso de error.

Es la parte que convierte la historia en algo construible. Si no se pueden escribir, falta conversación.

Qué queda afuera

Lo que alguien podría suponer incluido y no lo está.

Evita la discusión más frecuente al entregar: «yo pensé que también hacía…».

Notas y dependencias

Datos de contexto, diseños, si depende de otro equipo o de un dato que todavía no existe.

Las dependencias escritas antes son planificación; descubiertas después, son un atraso.

No hace falta llenarla entera para todo. Para una historia chica, título y criterios alcanzan.

El tamaño y por qué importa

Una historia que lleva tres semanas no es una historia grande: es varias historias sin separar. Y ya sabemos qué le pasa al trabajo que tarda: engorda la cola y demora todo lo demás.

Forma de cortarEjemploCuándo usarla
Por caso de usoPrimero exportar la tabla completa; después con filtrosCasi siempre: entrega valor desde la primera
Por tipo de datoPrimero clientes; después facturasCuando cada tipo tiene reglas distintas
Por regla de negocioPrimero el caso general; después las excepcionesCuando las excepciones son pocas y raras
Por camino feliz y erroresPrimero que funcione; después los errores y avisosSólo si se puede usar de verdad mientras tanto
Por capa técnicaPrimero el backend; después el frontendCasi nunca: ninguna de las dos entrega nada sola
La última fila es la forma más común de cortar y la que menos sirve: se entregan mitades que nadie puede usar.

Antes de seguir, predecí

Una historia grande se puede cortar en «hacer la API» y «hacer la pantalla», o en «exportar sin filtros» y «agregar filtros». ¿Cuál conviene?

La definición de terminado

Los criterios de aceptación son de cada historia. La definición de terminado es del equipo y vale para todas: es lo que evita que «listo» signifique cosas distintas para cada persona.

Una definición de terminado típica

  1. El código está revisado y fusionado.
  2. Los criterios de aceptación se verificaron, no sólo el camino feliz.
  3. Hay tests de la lógica central y pasan.
  4. Está desplegado en el entorno que corresponda.
  5. Funciona ahí, verificado por quien lo hizo.
  6. Quien lo pidió lo sabe.

Lo que preguntan sobre esto

Cierre

Autoevaluación

¿Lo entendiste?

¿Qué hace útil a una historia de usuario?
¿Cuál es el problema de una historia que describe la solución técnica?
¿Cuál es la peor forma de cortar una historia grande?
¿Qué diferencia hay entre criterios de aceptación y definición de terminado?
¿Cuál es la parte más salteada al escribir una historia?