स्वीकृति मानदंड के साथ यूज़र स्टोरी टेम्पलेट (मुफ्त)

एक यूज़र स्टोरी टेम्पलेट दो काम करता है। यह हर कहानी को एक ही तीन प्रश्नों (कौन, क्या, क्यों) का उत्तर देने के लिए मजबूर करता है, और यह टीम को एक निश्चित स्थान देता है जहाँ वे लिख सकते हैं कि वे कैसे जानेंगे कि कहानी पूरी हो गई है। यह पेज आपको दोनों देता है: एक-लाइन कहानी प्रारूप, एक पूर्ण कार्ड टेम्पलेट जिसे आप कॉपी कर सकते हैं, तीन प्रारूपों में स्वीकृति मानदंड, तैयार और पूर्ण होने की परिभाषा, और उदाहरणों के साथ व्याख्या।

यदि आप यूज़र स्टोरीज़ के लिए नए हैं, तो हमारे गाइड से शुरू करें यूज़र स्टोरीज़ कैसे लिखें, फिर टेम्पलेट के लिए यहाँ वापस आएं।

एक-लाइन यूज़र स्टोरी टेम्पलेट

अधिकांश टीमों 2001 में लंदन के Connextra टीम से निकले प्रारूप का उपयोग करती हैं और Mike Cohn की पुस्तक User Stories Applied (उन्हें यूज़र स्टोरीज़ का अवलोकन एक अच्छा प्रारंभिक संदर्भ है):

एक [उपयोगकर्ता प्रकार] के रूप में, मैं [एक क्रिया या क्षमता] चाहता हूँ, ताकि [एक लाभ या परिणाम]।

हर भाग एक विशिष्ट काम करता है:

• “एक” एक वास्तविक उपयोगकर्ता प्रकार का नाम देता है, जैसे कि एक नया खरीदार, एक खाता एडमिन या एक लौटता मरीज़। “एक उपयोगकर्ता के रूप में” टीम को कुछ भी नहीं बताता है। यदि आपके पास पर्सना हैं, तो उनके नामों का उपयोग करें।
• “मैं चाहता हूँ” यह वर्णन करता है कि उपयोगकर्ता क्या करता है या क्या प्राप्त करता है, उनके शब्दों में। इसमें समाधान का वर्णन नहीं होना चाहिए (“एक ड्रॉपडाउन”, “एक Redis cache”); टीम को सबसे अच्छा समाधान खोजने के लिए स्थान छोड़ें।
• “ताकि” मूल्य को दर्शाता है। यह वह भाग है जिसे सबसे अक्सर छोड़ा जाता है और जो सबसे ज़्यादा मायने रखता है: यह वह तरीका है जिससे टीम एक सरल विकल्प प्रस्तावित कर सकती है जो उसी परिणाम को प्रदान करता है, और जिससे प्रोडक्ट ओनर प्राथमिकता तय करता है।

ध्यान रखें कि वाक्य आवश्यकता नहीं है। Ron Jeffries ने कहानी को तीन चीज़ों के रूप में वर्णित किया: कार्ड, संवाद और पुष्टि (3 Cs)। एक टेम्पलेट कार्ड और पुष्टि (स्वीकृति मानदंड) में मदद करता है; संवाद की कोई जगह नहीं ले सकता।

पूरा यूज़र स्टोरी कार्ड टेम्पलेट

एक-लाइनर एक स्टिकी नोट के लिए पर्याप्त है। एक बैकलॉग टूल में आपको आमतौर पर कुछ और फ़ील्डों की आवश्यकता होती है ताकि कहानी को रैंक, अनुमानित और परीक्षण किया जा सके। ये वे फ़ील्ड हैं जो हम उपयोगी पाते हैं; अपनी टीम द्वारा कभी नहीं पढ़ी जाने वाली किसी भी फ़ील्ड को छोड़ दें।

“Context and notes” को छोटा रखें: यदि यह स्पेसिफिकेशन की एक पेज बन जाता है, तो स्टोरी संभवतः एक एपिक है और इसे विभाजित करने की आवश्यकता है (हमारा स्टोरी मैपिंग गाइड दिखाता है कि कैसे)।

कॉपी-रेडी यूज़र स्टोरी टेम्पलेट

इसे Jira या Linear issue के विवरण फ़ील्ड, Notion डेटाबेस टेम्पलेट, या स्प्रेडशीट के हेडर रो में पेस्ट करें। ब्रैकेटेड टेक्स्ट को बदलें और उन पंक्तियों को हटा दें जो आप उपयोग नहीं करते हैं।

• ID: [PROJECT-000]
• शीर्षक: [Verb + object, जैसे “Export invoices to CSV”]
• स्टोरी: एक [उपयोगकर्ता प्रकार] के रूप में, मुझे [कार्रवाई या क्षमता] चाहिए, ताकि [लाभ]।
• संदर्भ: [यह अभी क्यों महत्वपूर्ण है; रिसर्च, सपोर्ट टिकट या मेट्रिक्स से लिंक]
• स्वीकृति मानदंड: [3 से 7 परीक्षण योग्य शर्तें, चेकलिस्ट या Given/When/Then रूप में]
• स्कोप के बाहर: [यह स्टोरी जानबूझकर क्या कवर नहीं करती]
• डिज़ाइन: [फ्रेम या प्रोटोटाइप से लिंक]
• निर्भरताएँ: [अन्य स्टोरीज़, सर्विसेज़ या निर्णय]
• प्राथमिकता: [Must / Should / Could, या बैकलॉग रैंक]
• अनुमान: [पॉइंट्स या साइज़, टीम द्वारा भरा गया]
• खुले प्रश्न: [सप्रिंट शुरू होने से पहले जवाब दिए जाने वाले कुछ भी]

“Out of scope” पंक्ति बहसों से बचाती है: कार्ड पर “SMS reset शामिल नहीं है” लिखना, सप्रिंट रिव्यू में यह खोजने से बेहतर है कि किसी ने इसे शामिल मान लिया था।

स्वीकृति मानदंड क्या हैं, और इन्हें कौन लिखता है

स्वीकृति मानदंड वे शर्तें हैं जिनकी पूर्ति होने पर प्रोडक्ट ओनर स्टोरी को स्वीकार करता है। ये उपयोगकर्ता के दृष्टिकोण से अवलोकन योग्य व्यवहार का वर्णन करते हैं, यह नहीं कि कोड कैसे काम करता है। अच्छे मानदंड हैं:

• परीक्षण योग्य: कोई भी व्यक्ति बिना व्याख्या किए हाँ या नहीं कह सकता है। “तेज़” परीक्षण योग्य नहीं है; “परिणाम दो सेकंड के भीतर प्रकट होते हैं” परीक्षण योग्य है।
• इस स्टोरी के लिए विशिष्ट: जो नियम हर स्टोरी पर लागू होते हैं (कोड समीक्षा, स्टेजिंग पर डेप्लॉयमेंट) definition of done में आते हैं, यहाँ नहीं।
• इम्प्लीमेंटेशन विवरण से मुक्त: यह कहें कि क्या होता है, यह नहीं कि कौन सा कंपोनेंट या टेबल इसे संभव बनाता है।
• विफलता के बारे में ईमानदार: कम से कम एक मानदंड अमान्य इनपुट, नेटवर्क की अनुपलब्धता या अनुमतियों की कमी को कवर करता है।
• कम: तीन से सात मानदंड एक स्वस्थ सीमा है। दस से अधिक आमतौर पर इसका अर्थ है कि स्टोरी को विभाजित किया जाना चाहिए।

प्रोडक्ट ओनर मानदंडों के लिए ज़िम्मेदार है, लेकिन इन्हें अकेले नहीं लिखना चाहिए। सबसे भरोसेमंद पैटर्न प्रोडक्ट, एक डेवलपर और एक टेस्टर के बीच एक छोटी रिफ़ाइनमेंट बातचीत है (जिसे अक्सर “three amigos” कहा जाता है): मूल्य क्या है, इसका निर्माण कैसे किया जाएगा, यह कैसे टूट सकता है।

फ़ॉर्मेट 1: चेकलिस्ट स्वीकृति मानदंड

शर्तों की एक साधारण सूची। यह लिखने और पढ़ने का सबसे तेज़ फ़ॉर्मेट है, और यह सरल स्टोरीज़ और मैन्युअली परीक्षण करने वाली टीमों के लिए अच्छा काम करता है।

स्टोरी: एक लौटने वाले ग्राहक के रूप में, मुझे ईमेल द्वारा अपना पासवर्ड रीसेट करना है, ताकि मैं सपोर्ट से संपर्क किए बिना अपने अकाउंट में वापस आ सकूँ।

• लॉगिन स्क्रीन पर “Forgot password?” लिंक है जो रीसेट फ़ॉर्म खोलता है।
• पंजीकृत ईमेल पते को सबमिट करने पर एक मिनट के भीतर रीसेट लिंक भेजा जाता है।
• रीसेट लिंक एक बार काम करता है और 30 मिनट के बाद समाप्त हो जाता है।
• नया पासवर्ड मौजूदा पासवर्ड नियमों को पूरा करना चाहिए, और फ़ॉर्म बताता है कि कौन सा नियम विफल रहा।
• सफल रीसेट के बाद, उस खाते के लिए सभी अन्य सत्र साइन आउट कर दिए जाते हैं।
• अनपंजीकृत पते को सबमिट करने पर पंजीकृत पते के समान पुष्टि संदेश दिखाया जाता है, इसलिए फॉर्म यह प्रकट नहीं करता कि किसके पास खाता है।

जब व्यवहार सरल हो, तब चेकलिस्ट का उपयोग करें। इसकी कमज़ोरी यह है कि यह प्रारंभिक स्थिति और घटनाओं का क्रम छिपा देता है, जो अगले प्रारूप स्पष्ट करता है।

प्रारूप 2: Given/When/Then (Gherkin) स्वीकृति मानदंड

Given/When/Then व्यवहार-चालित विकास (behaviour-driven development) से आता है, जिसे Dan North ने Chris Matts के साथ वर्णित किया था Introducing BDD। हर परिदृश्य एक प्रारंभिक संदर्भ (Given), एक क्रिया (When) और एक अपेक्षित परिणाम (Then) का उल्लेख करता है। Gherkin Cucumber और समान उपकरणों द्वारा उपयोग की जाने वाली इस भाषा का संरचित संस्करण है, इसलिए इस तरह लिखे गए परिदृश्यों को थोड़े बदलाव के साथ स्वचालित परीक्षणों में बदला जा सकता है।

यहाँ वही पासवर्ड रीसेट कहानी तीन परिदृश्यों के रूप में दी गई है, जिसमें दो असफल पथ शामिल हैं।

परिदृश्य 1: वैध लिंक के साथ रीसेट

• Given मेरे पास anna@example.com के लिए पंजीकृत खाता है
• And मैंने पासवर्ड रीसेट का अनुरोध किया है
• When मैं 30 मिनट के भीतर रीसेट लिंक खोलता हूँ और नियमों को पूरा करने वाला नया पासवर्ड दर्ज करता हूँ
• Then मेरा पासवर्ड बदल दिया जाता है
• And मैं साइन इन हो जाता हूँ
• And मेरे अन्य सत्र साइन आउट कर दिए जाते हैं

परिदृश्य 2: लिंक समाप्त हो गया है

• Given मैंने 30 मिनट से अधिक समय पहले पासवर्ड रीसेट का अनुरोध किया था
• When मैं रीसेट लिंक खोलता हूँ
• Then मुझे एक संदेश दिखता है कि लिंक समाप्त हो गया है
• And मुझे नया लिंक भेजने के लिए बटन प्रदान किया जाता है

परिदृश्य 3: ईमेल पता पंजीकृत नहीं है

• Given sam@example.com के लिए कोई खाता मौजूद नहीं है
• When मैं sam@example.com के लिए पासवर्ड रीसेट का अनुरोध करता हूँ
• Then मुझे वही पुष्टि संदेश दिखता है जो पंजीकृत उपयोगकर्ता को दिखता है
• And कोई ईमेल नहीं भेजा जाता

जब एक परिदृश्य को कई इनपुट के साथ चलाने की आवश्यकता होती है (जैसे, अस्वीकृत होने वाले पासवर्ड की सूची), तो Gherkin का Scenario Outline आपको इसे एक बार लिखने और इनपुट को एक उदाहरण तालिका में सूचीबद्ध करने की अनुमति देता है।

Gherkin को पठनीय रखें: एक परिदृश्य प्रति व्यवहार, और घोषणात्मक रूप से लिखें (“When I request a reset link”) बटन-दर-बटन (“When I click the Send button”) के बजाय, ताकि परिदृश्य पुनर्निर्माण के बाद भी टिकाऊ रहे।

प्रारूप 3: नियम-आधारित स्वीकृति मानदंड

उन कहानियों के लिए जो मुख्यतः व्यावसायिक नियमों (मूल्य निर्धारण, पात्रता, सत्यापन, अनुमतियाँ) पर आधारित हैं, नियमों को सीधे बताएं और केवल कठिन संयोजनों के लिए परिदृश्य जोड़ें।

कहानी: एक खरीदार के रूप में, मैं चेकआउट पर डिस्काउंट कोड लागू करना चाहता हूँ, ताकि मैं प्रचार मूल्य का भुगतान कर सकूँ।

• नियम 1: प्रति ऑर्डर एक कोड।
• नियम 2: प्रतिशत कोड केवल उत्पाद उप-योग पर लागू होता है, शिपिंग या कर पर नहीं।
• नियम 3: न्यूनतम खर्च वाला कोड केवल तभी लागू होता है जब डिस्काउंट से पहले उप-योग न्यूनतम को पूरा करता है।
• नियम 4: समाप्त या उपयोग किए गए कोड को अस्वीकार कर दिया जाता है, जिसमें कारण बताते हुए संदेश दिया जाता है।
• नियम 5: आइटम हटाने से उप-योग न्यूनतम से नीचे आ जाता है, जिससे कोड हट जाता है और सूचना दिखाई जाती है।

आप एक ही कहानी में विभिन्न प्रारूपों का मिश्रण कर सकते हैं। एक सामान्य पैटर्न है: तर्क के लिए नियम और उन मामलों के लिए दो या तीन Given/When/Then परिदृश्य जिनकी गलत व्याख्या होने की संभावना सबसे अधिक होती है।

तैयार होने की परिभाषा बनाम पूर्ण होने की परिभाषा

स्वीकृति मानदंड एक ही कहानी के लिए विशिष्ट होते हैं। तैयार होने की परिभाषा और पूर्ण होने की परिभाषा टीम-व्यापी समझौते होते हैं जो हर कहानी पर लागू होते हैं।

यह Scrum Guide पूर्ण होने की परिभाषा को Increment की उस स्थिति का औपचारिक वर्णन मानता है जब वह उत्पाद के लिए आवश्यक गुणवत्ता मापदंडों को पूरा करता है। तैयार होने की परिभाषा Scrum का हिस्सा नहीं है; यह एक अभ्यास है जिसे कई टीमों अपनाने का निर्णय लेती हैं ताकि आधा समझा गया काम किसी भी sprint में न आए (देखें Agile Alliance ग्लॉसरी पर तैयार होने की परिभाषा और definition of done).

तैयार होने की नमूना परिभाषा

• कहानी टेम्पलेट का पालन करती है और “so that” को भरा गया है।
• स्वीकृति मानदंड प्रोडक्ट, डेवलपमेंट और टेस्टिंग द्वारा लिखे और समीक्षित किए गए हैं।
• डिज़ाइन लिंक किए गए हैं, या टीम ने सहमति जताई है कि कोई डिज़ाइन आवश्यक नहीं है।
• निर्भरताएँ पूरी हो चुकी हैं या शेड्यूल की गई हैं।
• टीम ने इसका अनुमान लगा लिया है, और यह एक sprint में समा जाता है।

पूर्ण होने की नमूना परिभाषा

• सभी स्वीकृति मानदंड पास होते हैं।
• कोड की समीक्षा की गई और मुख्य शाखा में मर्ज किया गया।
• स्वचालित परीक्षण नए व्यवहार को कवर करते हैं और पूरा सूट पास होता है।
• बेसिक एक्सेसिबिलिटी जांच पास हो जाती हैं (कीबोर्ड उपयोग, लेबल, कंट्रास्ट)।
• इसे स्टेजिंग पर डेप्लॉय किया गया है और प्रोडक्ट ओनर ने इसे स्वीकार कर लिया है।

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

उदाहरण के रूप में उपयोग किए गए

विभिन्न प्रकार के प्रोडक्ट से दो और स्टोरी। चालीस और देखने के लिए, हमारे यूज़र स्टोरी उदाहरण.

SaaS: एक टीममेट को आमंत्रित करें (चेकलिस्ट)

एक वर्कस्पेस एडमिन के रूप में, मैं एक टीममेट को ईमेल के माध्यम से आमंत्रित करना चाहता हूँ, ताकि वे मेरे लॉगिन साझा किए बिना हमारे प्रोजेक्ट देख सकें।

• एडमिन को मीम्बर्स पेज पर एक “Invite” बटन दिखाई देता है; अन्य भूमिकाओं को नहीं।
• एडमिन भेजने से पहले भूमिका (Member या Admin) चुन सकता है।
• आमंत्रण ईमेल एक मिनट के भीतर आता है और लिंक सात दिनों के लिए वैध है।
• एक पते को आमंत्रित करना जो पहले से ही एक सदस्य है, एक संदेश दिखाता है, एक दूसरा आमंत्रण भेजने के बजाय।

ई-कॉमर्स: बाद के लिए एक आइटम सहेजें (Given/When/Then)

एक खरीदार के रूप में जो खरीदने के लिए तैयार नहीं है, मैं अपने कार्ट से एक आइटम को एक सेव्ड लिस्ट में ले जाना चाहता हूँ, ताकि मैं इसे फिर से खोज सकूं बिना मेरे ऑर्डर टोटल को प्रभावित किए।

• यदि मैं साइन इन कर चुका हूँ और मेरे कार्ट में दो आइटम हैं
• जब मैं एक आइटम पर “Save for later” चुनता हूँ
• तो वह आइटम मेरी सेव्ड लिस्ट में चला जाता है
• और मेरा कार्ट टोटल उसके बिना पुन: गणना किया जाता है
• यदि मैं साइन इन नहीं कर चुका हूँ
• जब मैं “Save for later” चुनता हूँ
• तो मुझसे साइन इन करने के लिए कहा जाता है, और आइटम तब सहेजा जाता है जब मैं ऐसा करता हूँ

Jira, Linear, Notion या एक स्प्रेडशीट में टेम्पलेट का उपयोग करना

Jira में, Story issue type का उपयोग करें और टेम्पलेट को विवरण में पेस्ट करें (या यदि आपके एडमिन ने एक डेडिकेटेड फील्ड जोड़ी है, तो एक्सेप्टेंस क्राइटेरिया को उसमें रखें)। Linear में, इसे एक issue template के रूप में सेव करें। Notion में, इसे एक डेटाबेस टेम्पलेट में रखें ताकि नई बैकलॉग पेज पहले से भरी हुई खोलें। एक स्प्रेडशीट जिसमें एक स्टोरी के लिए एक पंक्ति हो, पहली बैकलॉग या एक वर्कशॉप के लिए काम करती है, लेकिन एक बार जब कई लोग इसे एडिट करने लगें, तो एक ट्रैकर पर जाएं। चाहे टूल कुछ भी हो, टेम्पलेट इतना छोटा रखें कि लोग उसे भर सकें।

AI के साथ स्टोरी और एक्सेप्टेंस क्राइटेरिया का मसौदा तैयार करना

भाषा मॉडल स्टोरी और क्राइटेरिया के पहले मसौदे के लिए अच्छे हैं। एक प्रॉम्प्ट जो काम करता है:

आप एक प्रोडक्ट मैनेजर हैं। नीचे दिए गए फीचर के लिए, “As a [user], I want [action], so that [benefit]” फॉर्मेट में यूजर स्टोरी लिखें। हर स्टोरी के लिए, Given/When/Then रूप में 3 से 6 एक्सेप्टेंस क्राइटेरिया जोड़ें, जिसमें कम से कम एक अनहैपी पथ शामिल हो। किसी भी मान्यताओं और खुले प्रश्नों को अलग से सूचीबद्ध करें। फीचर: [फीचर, उपयोगकर्ताओं और किसी भी प्रतिबंधों का वर्णन करें]।

फिर मसौदे की समीक्षा किसी भी अन्य इनपुट की तरह करें:

• क्या उपयोगकर्ता एक वास्तविक सेगमेंट है जिससे आपने बात की है, या एक सामान्य “user”?
• क्या मॉडल ने बिजनेस नियम, सीमाएं या संख्याएं बनाई हैं? उन्हें अपने स्वयं के से बदलें।
• क्या अनहैपी पथ वे हैं जो आपके उपयोगकर्ता वास्तव में भिड़ते हैं? एक मसौदा कभी रिफाइनमेंट संवाद को प्रतिस्थापित नहीं करता है।

अक्सर पूछे जाने वाले प्रश्न

क्या आप चाहते हैं कि एक टीम आपके स्टोरी को काम करने वाले सॉफ्टवेयर में बदल दे? अपनी बैकलॉग लाएं, या बस विचार, और हम आपकी मदद करेंगे इसे स्पिंट-साइज़ स्टोरी में आकार देने और इसे बनाने में। देखें हमारे मासिक डेवलपमेंट प्लान.