¿Qué son los criterios INVEST?

I.N.V.E.S.T es el acrónimo de un conjunto de directrices, propuestas por Bill Wake, que sirven para evaluar la calidad de las historias de usuario en el desarrollo ágil de software. Cada letra describe un atributo deseable: Independiente, Negociable, Valiosa, Estimable, Small (pequeña) y Testeable. Antes de subir una historia al backlog del producto o de llevarla a un sprint, el Product Owner y el equipo comprueban que cumpla estos seis criterios. Si falla en alguno, la señal es clara: hay que reescribir la historia o dividirla en piezas más manejables.

INVEST no es una regla rígida sino una lista de comprobación rápida. Funciona igual de bien en Scrum que en Kanban, porque su objetivo es universal: que cada unidad de trabajo sea pequeña, clara y entregue valor por sí misma.

Una historia mal formulada contamina todo el flujo de trabajo. Si es demasiado grande, no cabe en una iteración y arrastra trabajo a medio terminar. Si es ambigua, el equipo discute en mitad del desarrollo en lugar de discutir antes. Si depende de otras tres historias, no se puede priorizar ni soltar de forma aislada. INVEST ataca todos esos problemas en el momento más barato para corregirlos: durante el refinamiento, antes de escribir una sola línea de código.

El resultado es un backlog donde las historias de arriba están listas para trabajarse y las de abajo todavía pueden ser grandes y difusas sin pasar nada. Esa es la idea de fondo: refinar de forma progresiva, no perfeccionar todo de golpe.

• Independiente. La historia debe ser autocontenida y no depender del orden de ejecución de otras. Las dependencias obligan a planificar en cadena y bloquean la priorización. Cuando dos historias se solapan, conviene fusionarlas o redibujar la frontera entre ellas.
• Negociable. Una historia es una invitación a conversar, no un contrato cerrado. Describe el qué y el por qué, no el cómo. Los detalles de implementación se acuerdan entre el equipo y el Product Owner; dejar margen evita soluciones impuestas que luego resultan caras o innecesarias.
• Valiosa. Cada historia tiene que entregar valor perceptible al usuario o al negocio. Las tareas puramente técnicas (montar una tabla, configurar un servicio) rara vez son buenas historias por sí solas; conviene formularlas desde el beneficio que habilitan.
• Estimable. El equipo debe tener información suficiente para estimar el esfuerzo, por ejemplo con puntos de historia. Si nadie sabe por dónde empezar, no es que falte capacidad de estimar: falta conocimiento, y suele resolverse con una investigación previa (un spike) o partiendo la historia.
• Small (pequeña). Debe caber holgadamente dentro de una iteración. Las historias pequeñas se entienden mejor, se estiman con menos error y dan retroalimentación más rápida. Si una historia ocupa casi todo el sprint, casi siempre se puede trocear por flujos, por reglas de negocio o por casos felices frente a casos límite.
• Testeable. Tiene que existir una forma objetiva de saber si está terminada, normalmente a través de sus criterios de aceptación. Si no se puede escribir una prueba o una condición verificable, la historia es demasiado vaga y volverá en forma de discusión al final.

Una historia bien formada según INVEST sería: "Como cliente, quiero filtrar el catálogo por precio para encontrar productos dentro de mi presupuesto."

• Independiente: funciona aunque no existan otros filtros.
• Negociable: no impone si el filtro es un deslizador, un campo numérico o rangos predefinidos.
• Valiosa: ayuda a la persona a comprar más rápido.
• Estimable: el equipo conoce el catálogo y puede calcular el esfuerzo.
• Small: cabe en un sprint sin comerse toda la capacidad.
• Testeable: se valida con criterios concretos como "al fijar un máximo de 50 €, solo aparecen productos de 50 € o menos".

Compárala con una historia que falla a INVEST: "Como cliente, quiero una mejor experiencia de búsqueda." No es estimable (no se sabe qué incluye), no es testeable (no hay condición de hecho) y no es pequeña (cabe todo dentro). La cura es dividirla en historias concretas: filtros por precio, ordenación, autocompletado, etc.

• Confundir INVEST con SMART. SMART se aplica a objetivos; INVEST, a historias de usuario. Comparten la idea de criterios claros, pero no son intercambiables.
• Tratar los seis criterios como obligatorios al 100 %. Son una guía heurística. Una historia puede ser ligeramente dependiente de otra y aun así trabajarse bien; el objetivo es detectar problemas, no rechazar historias por purismo.
• Forzar la independencia partiendo por capas técnicas. Dividir en "frontend" y "backend" rompe el valor: cada mitad deja de ser entregable. Es mejor partir en porciones verticales que aporten algo usable.
• Olvidar la T hasta el final. Si los criterios de aceptación se escriben cuando el desarrollo ya está avanzado, aparecen sorpresas y retrabajo justo antes del deploy.
• Estimar historias que no cumplen la E. Estimar sobre información insuficiente produce números inventados; primero hay que reducir la incertidumbre.

INVEST encaja de forma natural con otras prácticas del flujo ágil: se aplica durante el refinamiento del backlog, apoya la planificación del sprint y comparte espíritu con la Definition of Ready, que define cuándo una historia está lista para empezar, y la Definition of Done, que define cuándo está realmente terminada.