यूज़र स्टोरी कैसे लिखें (उदाहरण और acceptance criteria के साथ)
यूज़र स्टोरी किसी सुविधा का एक छोटा वर्णन है, यूज़र के नज़रिए से: “[किस तरह का यूज़र] के रूप में, मैं [लक्ष्य] चाहता हूँ ताकि [कारण]।” उसके नीचे acceptance criteria लिखें, यानी कुछ ठोस शर्तें जो सच होनी चाहिए ताकि स्टोरी पूरी मानी जाए। हर स्टोरी इतनी छोटी रखें कि एक बार में बनाई और टेस्ट की जा सके, और criteria ऐसे लिखें कि कोई भी उन्हें जाँच सके।
यूज़र स्टोरी एजाइल सॉफ़्टवेयर टीमों में लोकप्रिय हुईं, पर जब आप अकेले AI ऐप बिल्डर से बना रहे हों, तब भी वे उतनी ही उपयोगी हैं। एक अच्छी स्टोरी एक अच्छा prompt है।
फ़ॉर्मेट
यूज़र स्टोरी के तीन हिस्से होते हैं:
As a [कौन], I want [क्या] so that [क्यों]।
- कौन यूज़र का एक खास प्रकार है: पहली बार आने वाला विज़िटर, पेमेंट करने वाला सदस्य, क्लिनिक का रिसेप्शनिस्ट, एडमिन। “यूज़र” नहीं।
- क्या वह काम है जो वे करना चाहते हैं, उनके अपने शब्दों में। स्क्रीन कैसे काम करती है, यह नहीं।
- क्यों वह नतीजा है जिसकी उन्हें परवाह है। यह हिस्सा लोग अक्सर छोड़ देते हैं, और यही आपको गलत चीज़ बनाने से रोकता है।
उदाहरण:
As a जिम सदस्य, I want अपने फ़ोन से क्लास की बुकिंग रद्द करना so that वेटलिस्ट का कोई और मेरी जगह ले सके और मुझ पर no-show फ़ीस न लगे।
“क्यों” आपको वे दो बातें बताता है जो “क्या” नहीं बताता: यह फ़ोन पर काम करना चाहिए, और वेटलिस्ट व फ़ीस के नियम इसमें शामिल हैं।
Acceptance criteria
स्टोरी बताती है कि क्या चाहिए। Acceptance criteria बताती हैं कि वह कब पूरा हुआ। वे इतनी ठोस हों कि दो लोग सहमत हो सकें कि हर एक पास हुआ या नहीं।
इन्हें लिखने का एक आम तरीका है Given / When / Then:
- Given एक शुरुआती स्थिति
- When यूज़र कुछ करे
- Then यह नतीजा हो
जिम बुकिंग स्टोरी के लिए:
- Given मेरी बुकिंग बारह घंटे से ज़्यादा दूर है, when मैं Cancel दबाकर पुष्टि करूँ, then बुकिंग हट जाती है और मुझे “Booking cancelled” दिखता है।
- Given मैं एक बुकिंग रद्द करता हूँ और क्लास में वेटलिस्ट है, when रद्दीकरण सेव हो, then वेटलिस्ट पर पहले व्यक्ति को जगह और एक ईमेल मिलता है।
- Given बुकिंग बारह घंटे से कम दूर है, when मैं Cancel दबाऊँ, then पुष्टि से पहले मुझे दिखता है कि देर से रद्द करने की फ़ीस लागू होती है।
- Given मैं फ़ोन-चौड़ाई वाली स्क्रीन पर हूँ, then Cancel बटन बिना बगल में स्क्रॉल किए दिखता है।
सादी चेकलिस्ट भी चलती है, बशर्ते हर आइटम जाँचने योग्य हो। “रद्द करना आसान है” जाँचने योग्य नहीं है। “बुकिंग की सूची से रद्द करने में अधिकतम दो टैप लगते हैं” जाँचने योग्य है।
चरण-दर-चरण: अच्छी स्टोरी कैसे लिखें
चरण 1: एक असली यूज़र और एक असली समस्या से शुरू करें
एक तरह का यूज़र चुनें और कोई ऐसी दिक्कत जो उसे आज होती है। अगर आपने ग्राहकों से बात की है, तो उनके शब्द इस्तेमाल करें। “मैं हमेशा रद्द करना भूल जाता हूँ और मुझसे पैसे कट जाते हैं” “रद्दीकरण सुविधा जोड़ो” से बेहतर शुरुआती बिंदु है।
चरण 2: एक लाइन की स्टोरी लिखें
टेम्पलेट भरें। अगर आप एक भरोसेमंद “so that” नहीं लिख पा रहे, तो पूछें कि क्या यह सुविधा ज़रूरी भी है।
चरण 3: तीन से छह acceptance criteria जोड़ें
पहले मुख्य सफल स्थिति को कवर करें, फिर ज़रूरी विविधताएँ: अलग भूमिका, खाली स्थिति, कोई सीमा, कोई गलती। अगर आप छह से ज़्यादा लिख रहे हैं, तो स्टोरी शायद बहुत बड़ी है।
चरण 4: लिखें कि क्या दायरे से बाहर है
एक पंक्ति बहुत बातचीत बचा सकती है: “दायरे से बाहर: सशुल्क क्लासों का रिफ़ंड; एडमिन द्वारा सदस्यों की ओर से रद्द करना।” इससे बनाते समय स्टोरी बढ़ती नहीं।
चरण 5: INVEST से जाँचें
INVEST अच्छी स्टोरी की एक आम चेकलिस्ट है। स्टोरी ऐसी होनी चाहिए:
| अक्षर | मतलब | त्वरित जाँच |
|---|---|---|
| I | Independent (स्वतंत्र) | दूसरी स्टोरी का इंतज़ार किए बिना बन सके |
| N | Negotiable (समझौते योग्य) | ज़रूरत बताए, तय डिज़ाइन नहीं |
| V | Valuable (उपयोगी) | शिप होने पर यूज़र को फ़र्क दिखे |
| E | Estimable (आकलन योग्य) | आप मोटा अंदाज़ा लगा सकें कि कितनी बड़ी है |
| S | Small (छोटी) | एक बैठक में बने और टेस्ट हो |
| T | Testable (परखने योग्य) | हर acceptance criterion जाँची जा सके |
हर स्टोरी को अंक देना ज़रूरी नहीं है। यह तब सबसे उपयोगी है जब कोई स्टोरी गलत लगे और आप जानना चाहें कि क्यों।
अच्छे और खराब उदाहरण
| कमज़ोर स्टोरी | समस्या | बेहतर स्टोरी |
|---|---|---|
| As a user, I want a dashboard. | कोई खास यूज़र नहीं, कोई कारण नहीं, परखने योग्य नहीं | As a दुकान मालिक, I want आज के ऑर्डर और कमाई एक स्क्रीन पर देखना so that एक नज़र में पता चले कि दिन अच्छा जा रहा है या नहीं। |
| As an admin, I want the database to have a status column. | ज़रूरत नहीं, इम्प्लीमेंटेशन का वर्णन है | As an एडमिन, I want ऑर्डर को “shipped” चिह्नित करना so that ग्राहक यह पूछने के लिए ईमेल करना बंद करें कि उनका सामान कहाँ है। |
| As a customer, I want to manage my account. | बहुत बड़ी: कई सुविधाएँ एक में | As a ग्राहक, I want अपना ईमेल पता बदलना so that रसीदें मेरे नए इनबॉक्स में आएँ। |
| As a visitor, I want the site to be fast. | स्टोरी नहीं; ऐसी गुणवत्ता जो सबको चाहिए | इसे हर स्टोरी पर एक criterion के रूप में लिखें, या एक अलग परफ़ॉर्मेंस लक्ष्य के रूप में। |
बड़ी स्टोरी को कैसे बाँटें
बड़ी स्टोरियों पर ही प्रोजेक्ट अटकते हैं। आम तरीके:
- यूज़र की भूमिका के अनुसार। सदस्य अपनी बुकिंग रद्द करते हैं; स्टाफ़ किसी की भी।
- फ़्लो के चरण के अनुसार। क्लासें देखना; क्लास बुक करना; रिमाइंडर पाना।
- पहले सरल मामला। अभी एक मुफ़्त क्लास रद्द करना; फ़ीस और रिफ़ंड बाद की स्टोरी में।
- डेटा की विविधता के अनुसार। पहले एक स्थान का समर्थन; बाद में कई।
- पहले सही रास्ता, फिर गलतियाँ। पहले इसे काम करते हुए बनाएँ, फिर भरी हुई क्लास, खत्म पास आदि के लिए हैंडलिंग जोड़ें।
हर टुकड़ा अब भी ऐसा हो जिसे यूज़र इस्तेमाल कर सके और जिसका उसे फ़र्क दिखे।
यूज़र स्टोरी को prompts की तरह इस्तेमाल करना
Acceptance criteria वाली यूज़र स्टोरी AI ऐप बिल्डर के लिए एक अच्छे prompt के बहुत करीब है। यह AI को बताती है कि किसके लिए, क्या, क्यों, और “पूरा” की परिभाषा क्या है। हर संदेश में एक स्टोरी भेजें:
As a जिम सदस्य, I want अपने फ़ोन से क्लास बुकिंग रद्द करना so that वेटलिस्ट का कोई और मेरी जगह ले सके। Acceptance criteria:
- मेरी बुकिंग्स में हर बुकिंग पर Cancel हो, पुष्टि के चरण के साथ।
- क्लास से बारह घंटे से ज़्यादा पहले रद्द करने पर बस बुकिंग हट जाए।
- बारह घंटे से कम पहले हो, तो पुष्टि से पहले “A late-cancellation fee of $5 applies” दिखे, और फ़ीस बुकिंग पर दर्ज हो।
- अगर क्लास की वेटलिस्ट है, तो पहले व्यक्ति को जगह और ईमेल मिले।
- फ़ोन-चौड़ाई वाली स्क्रीन पर काम करे। दायरे से बाहर: रिफ़ंड, सदस्यों की ओर से स्टाफ़ द्वारा रद्द करना। इसे बनाएँ, फिर प्रिव्यू में हर criterion जाँचें और बताएँ कि कौन से पास हुए।
आप AI से किसी मोटे विचार से स्टोरी का ड्राफ़्ट भी बनवा सकते हैं, फिर उन्हें खुद संपादित करें:
मेरे ऐप का विचार: [दो-तीन वाक्य]। पहले संस्करण के लिए यूज़र स्टोरी लिखें, यूज़र प्रकार के अनुसार समूहित, हर एक के साथ 3 से 5 Given/When/Then acceptance criteria। बताएँ कि कौन सी लॉन्च के लिए ज़रूरी हैं और कौन सी बाद में चल सकती हैं।
हमेशा नतीजा पढ़ें और संपादित करें। AI आपके यूज़र नहीं जानता; आप जानते हैं।
Acceptance criteria आपकी टेस्ट योजना भी हैं। जब स्टोरी बन जाए, तो हर criterion खुद जाँचें। हमारी गाइड लॉन्च से पहले अपने ऐप को टेस्ट करना इसी पर आधारित है।
यूज़र स्टोरी अन्य दस्तावेज़ों में कहाँ फ़िट होती है
- प्रोडक्ट रिक्वायरमेंट्स डॉक्यूमेंट पूरे प्रोडक्ट का वर्णन करता है: समस्या, यूज़र, दायरा। यूज़र स्टोरी उसके अंदर की विस्तृत इकाइयाँ हैं। देखें AI से PRD कैसे लिखें।
- बग रिपोर्ट किसी ऐसी चीज़ का वर्णन करती है जो बन चुकी थी पर टूटी है। देखें अच्छी बग रिपोर्ट कैसे लिखें।
- MVP वह सबसे छोटा स्टोरी-सेट है जो मुख्य मूल्य देता है। देखें MVP क्या है।
आम गलतियाँ
- “As a user…” बहुत अस्पष्ट है। यूज़र का असली प्रकार नाम लें।
- “So that” छोड़ देना। कारण के बिना आप समझदारी से समझौते नहीं कर सकते।
- ज़रूरत के बजाय समाधान लिखना। “मुझे एक ड्रॉपडाउन चाहिए” किसी के सोचने से पहले ही एक डिज़ाइन पक्का कर देता है।
- ऐसे criteria जिन्हें टेस्ट नहीं किया जा सकता। “आसान”, “तेज़” और “सहज” इच्छाएँ हैं, criteria नहीं।
- वे स्टोरी जो असल में एपिक हैं। “अपना अकाउंट सँभालना” दस स्टोरी है।
- हर स्टोरी पहले से पूरी लिख देना। अगली कुछ स्टोरी विस्तार से लिखें; बाक़ी को एक-लाइन में रखें जब तक उन तक न पहुँचें।
Mythex में स्टोरी
Mythex में Plan मोड एक आइडिया को स्टोरी में बदलने के लिए अच्छी जगह है: एजेंट कुछ भी एडिट करने से पहले तरीके पर बात करता है। जब स्टोरी तैयार हो, तो Build पर जाएँ और उसे चिपकाएँ, हर संदेश में एक स्टोरी। हर एक के बाद /test प्रिव्यू में फ़्लो पर क्लिक करके जाँच सकता है, और अगर कोई जवाब गलत दिशा में गया तो उसे Revert to this point से वापस ले सकते हैं। डॉक्स में प्रभावी prompts देखें, और हमारी गाइड AI ऐप बिल्डर के लिए prompt कैसे लिखें भी।
यूज़र स्टोरी चेकलिस्ट
- किसी खास तरह के यूज़र का नाम है
- ज़रूरत बताता है, डिज़ाइन नहीं
- एक असली “so that” कारण है
- तीन से छह परखने योग्य acceptance criteria हैं
- कम से कम एक एज केस या गलती कवर है
- लिखा है कि क्या दायरे से बाहर है
- इतनी छोटी है कि एक बार में बने और टेस्ट हो
- बनने के बाद criteria एक-एक करके जाँची गईं
सवाल
यूज़र स्टोरी का फ़ॉर्मेट क्या है?
आम टेम्पलेट यह है: [किस तरह का यूज़र] के रूप में, मैं [कोई लक्ष्य] चाहता हूँ ताकि [कोई कारण]। इसके बाद acceptance criteria आती हैं, यानी शर्तों की एक छोटी सूची जो सच होनी चाहिए ताकि स्टोरी पूरी मानी जाए।
acceptance criteria क्या होती हैं?
Acceptance criteria ऐसी ठोस, जाँचने योग्य शर्तें हैं जो तय करती हैं कि कोई यूज़र स्टोरी कब पूरी है। इन्हें अक्सर Given / When / Then में लिखा जाता है: दी गई शुरुआती स्थिति, जब यूज़र कुछ करे, तब एक खास नतीजा हो।
यूज़र स्टोरी कितनी बड़ी होनी चाहिए?
इतनी छोटी कि एक बैठक में बनाई और टेस्ट की जा सके, फिर भी अपने आप में उपयोगी हो। अगर स्टोरी में पाँच या छह से ज़्यादा acceptance criteria हैं या वह कई स्क्रीन को छूती है, तो उसे यूज़र की भूमिका, फ़्लो के चरण, या पहले सरल मामले और बाद में एज केस के आधार पर बाँटें।
क्या AI से बनाते समय यूज़र स्टोरी उपयोगी है?
हाँ। acceptance criteria वाली यूज़र स्टोरी लगभग एक आदर्श prompt है: वह बताती है कि सुविधा किसके लिए है, उसे क्या चाहिए, और यह जाँचने का सटीक तरीका क्या है कि वह काम करती है। हर संदेश में एक स्टोरी भेजने से AI के बदलाव भी छोटे और टेस्ट करने में आसान रहते हैं।