"Als klant wil ik mijn betaalmethode opslaan, zodat ik de volgende keer sneller kan afrekenen." Dat is een gebruikersverhaal. Het is een zin, geen specificatie. Agile softwareteams schrijven ze op indexkaarten of post-it-briefjes. Deze opzet dwingt de schrijver om een ​​rol, een doel en een reden te benoemen. De focus blijft liggen op de persoon die de functionaliteit daadwerkelijk gaat gebruiken, en niet op het databaseschema.

Gebruikersverhalen werden eind jaren negentig populair gemaakt door Kent Beck en Ron Jeffries. Ze zijn bewust onvolledig. Het verhaal is een belofte voor een gesprek. Ontwikkelaars, ontwerpers en productmanagers bespreken de details. Acceptatiecriteria worden later toegevoegd. Een verhaal dat te groot is, wordt een epos genoemd. Een verhaal dat te vaag is, is een potentiële bug.

Drie C's

• Card: het geschreven verhaal, kort genoeg om op papier te passen.
• Conversation: de discussie die de hiaten opvult.
• Bevestiging: de tests die bewijzen dat het werkt.

Goede user stories zijn onafhankelijk, bespreekbaar, waardevol, inschatbaar, klein en testbaar. Het acroniem is INVEST. Het is geen religie. Sommige teams schrijven user stories als job stories: "Als ik te laat ben, wil ik met één tik kunnen betalen, zodat ik mijn trein niet mis." Hetzelfde idee, een andere invalshoek.