Una historia de usuario es una descripción breve y en lenguaje sencillo de una función desde la perspectiva del usuario. Captura quién quiere algo, qué quiere y por qué. Los criterios de aceptación definen qué significa "terminado" para esa historia — las condiciones que debe cumplir para ser aceptada.
As a [type of user]
I want [some goal]
so that [some benefit].
Example:
As a returning customer
I want to save my shipping address
so that I don't re-enter it every order.
La parte "so that" es la más importante — establece el valor, lo que ayuda al equipo a encontrar mejores soluciones que la solicitada literalmente.
Given a logged-in customer with a saved address
When they reach checkout
Then the saved address is pre-filled
And they can edit it before confirming
✓ Testable and unambiguous
✓ Defines done — no "I thought you meant..."
Independiente, Negociable, Valiosa, Estimable, Pequeña, Comprobable. Una historia demasiado grande para estimar o terminar en un sprint debe dividirse.
Las historias mantienen al equipo enfocado en el valor del usuario en lugar de una lista de tareas técnicas, e invitan a la conversación en lugar de dictar una solución.
Los criterios de aceptación claros evitan el punto de fricción más común en la entrega: construir algo que técnicamente funciona pero no es lo que realmente se necesitaba.