धुंधले Jira tickets की छिपी हुई कीमत

धुंधले tickets क्यों बने रहते हैं

सोमवार सुबह एक backend engineer एक ticket उठाती है। शीर्षक काफ़ी साफ़ लगता है: “Order updates के लिए user notifications जोड़ो।” Description में दो वाक्य हैं और तीन हफ़्ते पुराने Slack thread का एक link। पहली नज़र में यह काफ़ी साफ़ दिखता है। वह तीन दिन लगाकर ऐसा e-mail notification flow बना देती है जो order status के हर बदलाव पर चल पड़ता है।

गुरुवार को PR review के दौरान PM आता है और कहता है, “मेरा मतलब यह नहीं था। हमें तो सिर्फ shipping events के लिए in-app notifications चाहिए थीं, और users को उन्हें बंद करने का विकल्प भी होना था।” यहाँ किसी ने गलती नहीं की। कोई आलसी नहीं था। Ticket ने बस उन फैसलों को कभी सतह पर लाया ही नहीं, जिन्हें वह अपने अंदर छिपाए बैठा था।

कोई भी जानबूझकर धुंधला ticket नहीं लिखता। वह दो बैठकों के बीच दो मिनट में लिखा जाता है, इस सच्चे इरादे के साथ कि बाद में वापस आकर details जोड़ दी जाएँगी। लेकिन वह “बाद में” आता नहीं। लिखने वाले के दिमाग़ में पूरा context मौजूद होता है। उसे पता होता है कि कौन-से events मायने रखते हैं, कौन-से channels दिमाग़ में हैं, और किन users पर असर पड़ेगा।

यह सब page पर नहीं आता, क्योंकि लिखने वाले को यह साफ़-साफ़ समझ में आता है। बाकी लोगों को नहीं।

Jira इस समस्या को और बढ़ा देता है, क्योंकि इसमें यह सब बहुत आसान है। ऐसा कोई required field नहीं है जो पूछे कि साफ़ तौर पर scope के बाहर क्या है। ऐसा कोई guardrail नहीं है जो बीस शब्दों से कम का description अस्वीकार कर दे। आप summary field में तीन शब्द लिखकर, description खाली छोड़कर Create दबा सकते हैं। Jira आपको रोकेगा नहीं। यही उसकी सुविधा भी है और जाल भी। नतीजा यह होता है कि backlog ऐसे tickets से भर जाता है जो ऊपर-ऊपर से पूरे लगते हैं, लेकिन उनकी धुंधलाहट का पता तभी चलता है जब कोई उन्हें बनाना शुरू करता है।

उतनी ही मेहनत बिखरी और असमंजस भरी रह सकती है, या ticket के साफ़ होते ही व्यवस्थित और buildable बन सकती है.

सचमुच build-ready plan में क्या होता है

ज़्यादातर tickets एक सवाल का जवाब देते हैं: हमें क्या चाहिए? एक build-ready plan छह सवालों का जवाब देता है।

हिस्सा	यह किसका जवाब देता है
Scope	क्या इसमें शामिल है, और क्या साफ़ तौर पर बाहर है
Constraints	क्या बदला नहीं जा सकता या टूटना नहीं चाहिए
Steps	क्या होना है, और किस क्रम में
Edge cases	जब सीधी राह काम न करे तो क्या होगा
Dependencies	पहले से क्या मौजूद होना चाहिए
Definition of done	सबको कैसे पता चलेगा कि काम सच में पूरा हो गया है

यह backlog के हर छोटे bug fix के लिए checklist नहीं है। लेकिन जो भी चीज़ sprint में जा रही है, जो किसी का कुछ घंटों से ज़्यादा समय लेगी, उसके लिए काम शुरू होने से पहले इन सवालों के जवाब होना ज़रूरी है। Scope वह हिस्सा है जिसे टीमें सबसे ज़्यादा छोड़ देती हैं। क्या बाहर है, यह तय करना बेकार लगता है, क्योंकि सबका ध्यान इस पर होता है कि अंदर क्या है। लेकिन हैरानी की बात यह है कि rework का बड़ा हिस्सा यहीं से शुरू होता है।

Constraints वे ख़ामोश requirements हैं:

मौजूदा order e-mail flow को मत तोड़ो।
मौजूदा notification service के भीतर ही रहो।
इस sprint में कोई नई infrastructure नहीं।

ये बातें अक्सर लिखी नहीं जातीं, क्योंकि लिखने वाला मान लेता है कि सबको यह पहले से पता है। ऐसा नहीं होता। और definition of done वह रेखा है जो “मुझे लगता है यह पूरा है” और “हम सब मानते हैं कि यह पूरा है” के बीच आती है। अच्छी definition of done देखी भी जा सकती है और परखी भी जा सकती है।

Build-ready plan सिर्फ ज़्यादा text नहीं होता। यह एक structured workspace होता है, जहाँ scope, constraints, dependencies, edge cases, steps और definition of done साफ़ दिखते हैं.

Structure से पहले सवाल आते हैं

हर Jira instance आखिरकार एक ही चक्र से गुजरती है। कोई description template जोड़ देता है, जिसमें Summary, Acceptance Criteria, Technical Notes और Out of Scope जैसे sections होते हैं। कुछ हफ़्तों तक लोग उसे भरते हैं। फिर वही धुंधली भाषा, जो पहले खाली description में रहती थी, अब बस अलग-अलग labelled boxes में फैल जाती है। Structure बेहतर हो गई। सोच नहीं।

Templates समस्या हल नहीं करते, क्योंकि समस्या structure की नहीं है। समस्या cognitive है। लिखने वाले को ही नहीं पता कि वह क्या छोड़ रहा है। Edge Cases नाम का एक खाली section, उस व्यक्ति की मदद नहीं करता जिसने अभी तक edge cases पर सोचा ही नहीं है। सवाल मदद करते हैं। साफ़, ठोस सवाल, जो निर्णय निकलवाते हैं।

पाँच सवाल खास तौर पर छिपे हुए निर्णय सामने लाते हैं:

System behavior में क्या बदल रहा है?
मुख्य उपयोगकर्ता कौन है, और वह क्या हासिल करना चाहता है?
क्या कोई ऐसा मामला है जब यह होना ही नहीं चाहिए?
अगर हम यह ship न करें तो क्या टूटेगा?
क्या यह मौजूदा users पर लागू है, नए users पर, या दोनों पर?

ये सवाल इसलिए काम करते हैं क्योंकि ये इतने ठोस हैं कि जवाब दिए जा सकें, और इतने व्यापक हैं कि लगभग हर feature ticket पर लागू हो सकें। इनका जवाब देना ही planning है। Template सिर्फ वह जगह है जहाँ जवाब जाकर बैठते हैं।

Structure से पहले सवाल आने चाहिए: पहले कच्ची request, फिर clarification, फिर plan assembly, और आखिर में execution-ready output.

पूरा उदाहरण

व्यवहार में यह कुछ ऐसा दिखता है। मूल ticket बहुत छोटा है: “Order updates के लिए user notifications जोड़ो।” Description बस इतना कहता है कि order status बदलने पर users को notification मिलनी चाहिए, और visual treatment के लिए design से बात कर लेनी है। यह उसे sprint में खींच लाने के लिए काफ़ी है, लेकिन भरोसे के साथ build करने के लिए बिलकुल काफ़ी नहीं।

स्पष्टता के छोटे-से दौर से सब बदल जाता है:

Clarifying question	Answer
कौन-सी status changes मायने रखती हैं?	सिर्फ shipped और delivered
कौन-से channels?	इस sprint में सिर्फ in-app
क्या users इन्हें बंद कर सकते हैं?	हाँ, default opt-in के साथ
Offline users का क्या?	अगली login तक notification queue में रहेगी
क्या यह मौजूदा orders पर भी लागू है?	नहीं, सिर्फ नए orders पर
अगर delivery fail हो जाए तो?	एक बार retry, फिर log

पंद्रह मिनट बाद वही ticket सबके लिए एक ही बात कहता है। बाद वाली version में असली scope है, असली constraints हैं, क्रमबद्ध steps हैं, वास्तविक edge cases हैं, और ऐसी definition of done है जिसे test किया जा सकता है। Ticket वही है। स्पष्टता पूरी तरह अलग है। फर्क बेहतर template का नहीं है। फर्क सिर्फ इतना है कि काम शुरू होने से पहले थोड़ी-सी सोच-समझकर पूछताछ की गई।

इस प्रक्रिया में AI कहाँ फिट होती है

AI tickets नहीं लिखती। Tickets लोग लिखते हैं। लेकिन प्रक्रिया में एक बहुत खास जगह पर AI उपयोगी है: तब, जब intent मौजूद हो, लेकिन structure अभी final न हुई हो। Language model धुंधला description पढ़कर पूछ सकती है, “क्या आपने सोचा कि user offline हो तो क्या होगा?” वह Slack thread में बिखरे जवाबों को scope, constraints और steps में बदल सकती है। वह यह भी पकड़ सकती है कि plan में database migration का ज़िक्र है, लेकिन dependency list में सही लोगों की review का कोई ज़िक्र नहीं है।

जिस काम में AI अच्छी नहीं है, वह है आपके product के फैसले लेना। वह पूछ सकती है कि यह e-mail होना चाहिए, push होना चाहिए या in-app। लेकिन वह तय नहीं कर सकती कि आपके users और आपके sprint के लिए कौन-सा विकल्प सही है। वह plausible definition of done लिख सकती है, लेकिन वह सचमुच सही है या नहीं, यह सिर्फ वही इंसान जान सकता है जो product समझता हो।

Pattern सीधा है: इंसान फैसला करते हैं, AI उसे व्यवस्थित करती है। इंसान scope तय करते हैं, AI gaps पकड़ती है। Jira के भीतर Just on Atlassian Marketplace इसी pattern के आसपास बना है: clarify, plan, execute. यही pattern हाथ से भी काम करता है। AI बस इस चक्र को तेज़ कर देती है।

आज ही लागू करने लायक तीन बातें

अगले sprint से पहले, अपने backlog का सबसे धुंधला ticket चुनो और किसी के code लिखने से पहले इस article के पाँच सवाल पूछो। लगभग तय है कि कम से कम दो ऐसे फैसले मिलेंगे, जिनके बारे में किसी को पता ही नहीं था कि वे अभी तक लिए नहीं गए हैं।
जवाबों को scope, constraints और testable definition of done के रूप में लिखो, किसी अलग document में नहीं, बल्कि ticket के भीतर, वहीं जहाँ उसे build करने वाला सचमुच देखेगा।
ऊपर दिए गए template को शुरुआत मानो, नियम-पुस्तिका नहीं। उसे अपनी टीम की भाषा के हिसाब से ढालो, लेकिन सवाल मत छोड़ो। अगर तुम वह बड़ा संदर्भ समझना चाहते हो कि vague tickets को सीधे AI को सौंपने पर यह clarification step और भी ज़रूरी क्यों हो जाती है, तो इस series का पहला article alignment problem को विस्तार से समझाता है: क्यों Jira के ज़्यादातर AI tools alignment problem को बेहतर करने के बजाय बदतर बना देते हैं.

जब बुनियाद व्यवस्थित हो जाती है, तो टीम हिचकिचाना छोड़ देती है और अगला कदम कहीं ज़्यादा साफ़ होकर सामने आता है.