«Como comprador, quiero guardar mi método de pago para poder finalizar la compra más rápido la próxima vez». Esa es una historia de usuario. Es una frase, no una especificación. Los equipos de desarrollo ágil las escriben en fichas o notas adhesivas. El formato obliga al autor a definir un rol, un objetivo y una razón. Así, el enfoque se centra en la persona que realmente usará la función, no en el esquema de la base de datos.

Las historias de usuario fueron popularizadas por Kent Beck y Ron Jeffries a finales de la década de 1990. Son deliberadamente incompletas. La ficha es una promesa de conversación. Desarrolladores, diseñadores y gerentes de producto discuten los detalles. Los criterios de aceptación se añaden posteriormente. Una historia demasiado extensa se denomina épica. Una historia demasiado vaga es un posible error.

Las tres C

• Card: la historia escrita, lo suficientemente corta como para caber en papel.
• Conversación: la discusión que llena los vacíos.
• Confirmación: las pruebas que demuestran que funciona.

Las buenas historias son independientes, negociables, valiosas, estimables, breves y comprobables. El acrónimo es INVEST. No es una religión. Algunos equipos escriben historias como si fueran historias de trabajo: «Cuando llego tarde, quiero pagar con un solo clic para no perder el tren». La misma idea, con un enfoque diferente.