"एक ग्राहक के तौर पर, मैं अपना भुगतान तरीका सेव करना चाहता हूँ ताकि अगली बार मैं जल्दी भुगतान कर सकूँ।" यह एक यूज़र स्टोरी है। यह एक वाक्य है, कोई स्पेसिफिकेशन नहीं। एजाइल सॉफ्टवेयर टीमें इन्हें इंडेक्स कार्ड या स्टिकी नोट्स पर लिखती हैं। यह फॉर्मेट लेखक को एक भूमिका, एक लक्ष्य और एक कारण बताने के लिए बाध्य करता है। यह डेटाबेस स्कीमा पर नहीं, बल्कि उस व्यक्ति पर ध्यान केंद्रित रखता है जो वास्तव में इस फीचर का उपयोग करेगा।

यूज़र स्टोरीज़ को 1990 के दशक के उत्तरार्ध में केंट बेक और रॉन जेफ़रीज़ ने लोकप्रिय बनाया था। ये जानबूझकर अपूर्ण होती हैं। यह एक तरह से आगे की बातचीत का वादा है। डेवलपर्स, डिज़ाइनर और प्रोडक्ट मैनेजर इसके विवरण पर चर्चा करते हैं। स्वीकृति मानदंड बाद में जोड़े जाते हैं। बहुत बड़ी स्टोरी को एपिक कहा जाता है। बहुत अस्पष्ट स्टोरी किसी बग का कारण बन सकती है।

तीन सी

• Card: लिखित कहानी, इतनी छोटी कि कागज पर समा जाए।
• Conversation: वह चर्चा जो कमियों को भर देती है।
• पुष्टि: वे परीक्षण जो यह साबित करते हैं कि यह काम करता है।

अच्छी कहानियां स्वतंत्र, समझौता योग्य, मूल्यवान, सराहनीय, संक्षिप्त और परीक्षण योग्य होती हैं। इसका संक्षिप्त रूप है INVEST (निवेश करना)। यह कोई धर्म नहीं है। कुछ टीमें कहानियों को नौकरी से जुड़ी कहानियों के रूप में लिखती हैं: "जब मुझे देर हो रही हो, तो मैं एक ही टैप से भुगतान करना चाहता हूं, ताकि मेरी ट्रेन न छूट जाए।" विचार वही है, बस दृष्टिकोण अलग है।