La buena historia: INVEST
En resumen: Una buena historia es independiente, negociable, valiosa, estimable, pequeña y comprobable. INVEST es una lista de comprobación para revisar, no una ley. La historia más cara es la que no se puede comprobar: nunca está terminada, porque nadie sabe cuándo lo está.
Problema
La historia que nunca acaba
Una historia lleva tres semanas en el tablero del equipo: «Como cliente quiero que el pago sea cómodo». El programador ha cambiado el formulario dos veces. La diseñadora ha cambiado los botones. Cada vez, el dueño dice «está mejor, pero no es esto».
La historia no está mal escrita. Tiene un rol, un objetivo y casi un beneficio. Pero nadie sabe decir cuándo está terminada, así que nunca lo está.
La idea
Seis letras
Bill Wake reunió las cualidades de una buena historia en una palabra: INVEST.
| Letra | Significa | Roto en la tienda |
|---|---|---|
| Independent (independiente) | se construye y se entrega sin otra historia al mismo tiempo | «introduzco el código» y «veo el descuento del código»: una no funciona sin la otra |
| Negotiable (negociable) | los detalles se negocian; la historia no es un contrato | «un botón rojo a la derecha, de 120 píxeles de ancho» |
| Valuable (valiosa) | aporta algo a alguien fuera del equipo | «preparar la base de datos para los códigos promocionales» |
| Estimable (estimable) | el equipo puede juzgar de qué tamaño es | «recomendaciones como las de las grandes tiendas», sin que nadie sepa por dónde empezar |
| Small (pequeña) | cabe en unos pocos días de trabajo | «gestiono mis pedidos»: cancelar, devoluciones, historial, direcciones |
| Testable (comprobable) | se puede decir cuándo está terminada | «el pago es cómodo» |
INVEST es una lista de comprobación para revisar. Recorres la historia letra por letra y preguntas: ¿está bien esto? Donde no, tienes una pregunta para la conversación.
Más precisamente, para curiosos
Bill Wake publicó INVEST en 2003 en el artículo «INVEST in Good Stories, and SMART Tasks». ISTQB CTFL v4.0.1 lo cita en la sección sobre la escritura colaborativa de historias de usuario.
La letra T es donde QA tiene más trabajo antes de que exista una sola línea de código. Una historia comprobable es la misma cualidad que un requisito verificable de la lección «El buen requisito»: sin una medida no hay prueba que pueda fallar.
Pruébalo
¿Qué letra?
En cada historia se rompe más una letra de INVEST. ¿Cuál?
La idea
La historia que no se puede comprobar
«El pago es cómodo» es la trampa del principio. Palabras como «cómodo», «rápido», «claro» y «adecuado» suenan a requisito, pero no dicen cuándo se cumplen. Cada uno las lee a su manera, y el dueño siempre puede decir «no es esto».
El arreglo no es una palabra más bonita. Es la pregunta «¿cómo sabremos que está terminada?» y una respuesta con casos concretos:
- «cómodo» se convierte en «un cliente nuevo paga sin ayuda en menos de 2 minutos», comprobado con cinco personas que nunca han visto la tienda;
- «rápido» se convierte en «el 95 % de los pagos se completa en menos de 3 segundos con 200 clientes a la vez»;
- «un mensaje claro» se convierte en «con un código caducado, el cliente ve “El código ha caducado” y el importe queda sin el descuento».
Ahora los tres (el negocio, QA y el programador) ven lo mismo. Esta es la tercera C, la confirmación, antes de que el trabajo haya empezado siquiera.
Pruébalo
¿Se puede comprobar?
La idea
Pequeña, pero aun así valiosa
Dos de las letras a menudo tiran en direcciones opuestas. La historia «gestiono mis pedidos» es valiosa, pero no pequeña. Si la cortas en «la base de datos de pedidos», «la pantalla de pedidos» y «el servicio de pedidos», cada trozo es pequeño, pero ninguno es valioso: el cliente no puede usar ninguno por sí solo.
La respuesta es cortar de modo que cada trozo atraviese todo lo que necesita y dé algo a alguien. «Cancelo un pedido pagado antes de que se envíe» es pequeña y valiosa. Cómo encontrar un corte así es el tema de la lección siguiente.
La letra E también apunta a algo. Cuando el equipo no puede estimar una historia, suele haber dos motivos: es demasiado grande o demasiado poco clara. Las grandes se dividen. Las poco claras se aclaran con preguntas, y para eso es la última lección del módulo.
Más precisamente, para curiosos
Cuando la parte poco clara es técnica («¿podemos hacer recomendaciones con nuestros datos?»), los equipos suelen hacer una investigación corta y limitada en el tiempo que se llama spike. No es una historia para el cliente. Su resultado es conocimiento que hace estimable la historia.
Ejercicio
Revisa las historias
1. Arregla la historia. Cuatro historias de la última reunión. Elige el mejor paso para cada una.
Test