मोबाइल डेवलपमेंट में टास्क ग्रूमिंग: यह क्या है, उद्देश्य और प्रक्रिया

टास्क ग्रूमिंग क्या है?

Backlog Grooming (परिशोधन) — आगामी स्प्रिंट के लिए Product Backlog कार्यों को तैयार करने की प्रक्रिया है। यह एक बैठक है जिसमें Product Owner और डेवलपमेंट टीम कार्यों की समीक्षा करते हैं: आवश्यकताओं को स्पष्ट करते हैं, Acceptance Criteria जोड़ते हैं, जटिलता का अनुमान लगाते हैं, निर्भरताएँ और जोखिम पहचानते हैं। Scrum Guide में “ग्रूमिंग” नामक कोई अनिवार्य घटना नहीं है — यह एक अतिरिक्त अभ्यास है जिसे Scrum टीमें Sprint Planning में अनिश्चितता कम करने के लिए अपनाती हैं। अनुशंसित आवृत्ति प्रति स्प्रिंट एक बार है, जो 60 मिनट से अधिक न हो।

“ग्रूमिंग” शब्द सार को दर्शाता है: टीम बैकलॉग को “कंघी” करती है, पुराने कार्यों को हटाती है, अस्पष्ट कार्यों को स्पष्ट करती है और बहुत बड़े कार्यों को तोड़ती है। मोबाइल डेवलपमेंट में, प्लेटफ़ॉर्म विशिष्टताओं के कारण ग्रूमिंग विशेष रूप से महत्वपूर्ण है: Android कार्य iOS संस्करण से जटिलता में भिन्न हो सकता है, और targetSdk, compileSdk और API स्तरों के साथ अनुकूलता पर विचार करना आवश्यक है। ग्रूमिंग के बिना, Sprint Planning अराजकता में बदल जाता है — टीम पहली बार कार्यों को देखती है और उनका अनुमान नहीं लगा सकती, जिससे अप्रत्याशितता और समय सीमा चूक जाती है।

ग्रूमिंग का परिणाम — Sprint Planning के लिए तैयार कई कार्य: उनके पास विवरण, Acceptance Criteria, अनुमान है और वे Definition of Ready को पूरा करते हैं। Product Owner को प्राथमिकता क्रम में कार्यों को ग्रूम करना चाहिए: वर्तमान स्प्रिंट के निकटतम — सबसे विस्तृत। 3–4 स्प्रिंट आगे के कार्य — केवल एपिक स्तर पर। Progressive Refinement तकनीक: कार्य जितना स्प्रिंट के करीब होगा, उसका विवरण उतना ही विस्तृत होगा। वर्तमान स्प्रिंट के कार्यों के लिए — पूर्ण परिशोधन (AC, डिज़ाइन, API विशिष्टता)। 2 स्प्रिंट आगे के कार्यों के लिए — कहानी-स्तर (कार्यान्वयन विवरण के बिना उपयोगकर्ता कहानी)। 3+ स्प्रिंट आगे के कार्यों के लिए — एपिक-स्तर (केवल नाम और व्यावसायिक मूल्य)।

Definition of Ready: कार्य स्प्रिंट के लिए कब तैयार है

Definition of Ready (DoR) — मानदंडों की एक जाँच सूची है जिसे Sprint Backlog में शामिल करने से पहले एक कार्य को पूरा करना होता है। DoR Product Owner और टीम के बीच एक अनुबंध है: PO गारंटी देता है कि डेवलपमेंट के लिए सभी आवश्यक जानकारी उपलब्ध है, और टीम गारंटी देती है कि वह कार्य का अनुमान लगा सकती है और उसे पूरा कर सकती है। DoR सार्वभौमिक नहीं है — प्रत्येक टीम अपने स्वयं के मानदंड सेट को परिभाषित करती है। DoR के बिना, कोई कार्य अस्पष्ट आवश्यकताओं के साथ स्प्रिंट में प्रवेश कर सकता है, जिससे पुनः कार्य और समय सीमा चूक हो सकती है।

मोबाइल डेवलपमेंट के लिए विशिष्ट DoR: 1) Acceptance Criteria वर्णित हैं (Given-When-Then प्रारूप में)। 2) डिज़ाइन मॉकअप Figma में तैयार है (UI कार्यों के लिए) सभी अवस्थाओं के साथ: default, loading, error, empty state। 3) API विशिष्टता स्वीकृत है (OpenAPI/Swagger, अनुरोध और प्रतिक्रिया उदाहरण)। 4) स्टोरी पॉइंट्स में अनुमान उपलब्ध है। 5) अन्य कार्यों पर निर्भरताएँ पहचानी गई हैं। 6) कार्य अधूरे बाहरी घटकों पर निर्भर नहीं करता। 7) मोबाइल विशिष्टताएँ: लक्ष्य OS संस्करण परिभाषित, feature flag की आवश्यकता, पुराने API स्तरों के लिए समर्थन।

कार्य अनुमान तकनीकें

Planning Poker — ग्रूमिंग में सबसे लोकप्रिय अनुमान तकनीक है। प्रत्येक डेवलपर को फिबोनाची संख्याओं (1, 2, 3, 5, 8, 13, 21) वाले कार्ड का एक डेक मिलता है। PO एक कार्य प्रस्तुत करता है और उसे समझाता है। चर्चा के बाद, सभी एक साथ अपना कार्ड दिखाते हैं। यदि अनुमान काफी भिन्न होते हैं (उदाहरण के लिए, 3 और 13), तो डेवलपर्स अपने तर्क समझाते हैं, फिर दोबारा वोट करते हैं। पुनरावृत्तियाँ तब तक दोहराई जाती हैं जब तक आम सहमति नहीं बन जाती। Planning Poker का उद्देश्य सटीक अनुमान नहीं है, बल्कि कार्य की समझ में अंतर को उजागर करना है।

T-Shirt Sizing — त्वरित अनुमान के लिए एक सरलीकृत तकनीक: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13)। यह प्रारंभिक बैकलॉग छँटाई के लिए उपयुक्त है जब कई कार्य हों और आपको परिमाण का मोटा क्रम चाहिए। T-Shirt Sizing के बाद, अगले स्प्रिंट के कार्यों के लिए Planning Poker के माध्यम से अधिक सटीक अनुमान लगाया जाता है। Affinity Estimation — एक समूह छँटाई तकनीक है जहाँ कार्यों को संख्याओं का उपयोग किए बिना सबसे सरल से सबसे जटिल तक एक मेज पर व्यवस्थित किया जाता है, फिर समूहों में बाँटा जाता है, और प्रत्येक समूह को एक अनुमान मिलता है।

मोबाइल डेवलपमेंट में, अनुमान को प्लेटफ़ॉर्म जटिलता को ध्यान में रखना चाहिए। Android कार्य का अनुमान 5 SP हो सकता है जबकि iOS के लिए वही कार्य 3 SP हो सकता है (या इसके विपरीत)। यह सामान्य है: विभिन्न प्लेटफ़ॉर्म की कार्यान्वयन जटिलता अलग-अलग होती है। सुझाव: यदि टीम क्रॉस-प्लेटफ़ॉर्म है तो प्रत्येक प्लेटफ़ॉर्म का अलग-अलग अनुमान लगाएँ। एक सापेक्ष पैमाने का उपयोग करें: एक आधार कार्य (उदाहरण के लिए, टेक्स्ट और बटन वाली स्क्रीन) = 1 SP। बाकी सब कुछ उसके सापेक्ष है। Scrum.org (2025) के अनुसार, 3–4 स्प्रिंट के बाद, टीम की अनुमान सटीकता वास्तविक जटिलता के ±20% तक पहुँच जाती है।

विभाजन: बड़े कार्यों को कैसे तोड़ें

8 SP से बड़े कार्य को छोटे कार्यों में विभाजित किया जाना चाहिए। बड़े कार्यों को एक स्प्रिंट में पूरा नहीं किया जा सकता, उनका अनुमान लगाना कठिन होता है, और वे प्रगति की भावना नहीं देते। विभाजन तकनीकें: कार्य को क्षैतिज परतों (UI → ViewModel → Repository → Network/DB) या ऊर्ध्वाधर स्लाइस (सुविधा: एक पूर्ण स्क्रीन) में विभाजित करें। क्षैतिज विभाजन मोबाइल डेवलपमेंट के लिए बेहतर काम करता है: उप-कार्य 1 — UI लेआउट (XML/Jetpack Compose/SwiftUI), उप-कार्य 2 — ViewModel + State, उप-कार्य 3 — Repository + Network, उप-कार्य 4 — यूनिट परीक्षण।

ऊर्ध्वाधर विभाजन — उपयोगकर्ता कहानियों को स्वतंत्र मूल्य वाली छोटी कहानियों में विभाजित करना। उदाहरण: एपिक “शॉपिंग कार्ट” → कहानी 1 “कार्ट में आइटम जोड़ना”, कहानी 2 “कार्ट प्रदर्शित करना”, कहानी 3 “कार्ट से आइटम हटाना”, कहानी 4 “चेकआउट”। प्रत्येक कहानी का अपना व्यावसायिक मूल्य होता है और इसे स्वतंत्र रूप से जारी किया जा सकता है। SPoK (Kano पर स्टोरी पॉइंट्स): कहानियों को व्यावसायिक मूल्य (Must-have, Should-have, Could-have) के अनुसार क्रमबद्ध करें और मूल्य के क्रम में कार्यान्वित करें।

ग्रूमिंग पर विभाजन जाँच सूची: 1) क्या कार्य 8 SP से बड़ा है? → विभाजित करें। 2) क्या Acceptance Criteria परिभाषित हैं? → यदि नहीं, तो जोड़ें। 3) क्या यह अन्य कार्यों पर निर्भर करता है? → निर्भरताएँ पहचानें और दस्तावेज़ित करें। 4) क्या इसमें अनिश्चितता है? → मुख्य कार्य से पहले एक Spike (अनुसंधान) जोड़ें। 5) क्या डिज़ाइन की आवश्यकता है? → मॉकअप की तैयारी जाँचें। INVEST नियम: Independent (दूसरों से स्वतंत्र), Negotiable (चर्चा योग्य), Valuable (व्यवसाय के लिए मूल्यवान), Estimable (अनुमान योग्य), Small (छोटा), Testable (परीक्षण योग्य)। यदि कोई कार्य INVEST पूरा नहीं करता, तो वह स्प्रिंट के लिए तैयार नहीं है।

ग्रूमिंग प्रक्रिया: कदम दर कदम

चरण 1: वार्म-अप (5 मिनट)। Scrum Master टीम को ग्रूमिंग के उद्देश्य और DoR की याद दिलाता है। टीम बोर्ड को देखती है, और PO दिखाता है कि किन कार्यों पर चर्चा की जाएगी। चरण 2: कार्य समीक्षा (30 मिनट)। PO वर्तमान स्प्रिंट के अंत और अगले की शुरुआत से कार्यों को क्रमिक रूप से प्रस्तुत करता है। प्रत्येक कार्य के लिए: नाम, विवरण, Acceptance Criteria (यदि उपलब्ध हो), डिज़ाइन लिंक, API विशिष्टता। टीम स्पष्टीकरण प्रश्न पूछती है: “क्या खाली स्थिति के लिए मॉकअप है?”, “कौन सी HTTP विधि?”, “iOS का न्यूनतम डिप्लॉयमेंट टार्गेट क्या है?”

चरण 3: अनुमान (15 मिनट)। टीम Planning Poker या T-Shirt Sizing के माध्यम से कार्य का अनुमान लगाती है। यदि विसंगति 2 SP से अधिक है — वे कारणों पर चर्चा करते हैं और फिर से वोट करते हैं। नियम: यदि किसी कार्य का अनुमान नहीं लगाया जा सकता (आवश्यकताएँ स्पष्ट नहीं हैं, कोई डिज़ाइन नहीं) — इसे PO को सुधार के लिए वापस भेजा जाता है और यह स्पष्टीकरण के साथ अगले ग्रूमिंग में आएगा। अज्ञात कारकों वाले कार्यों का अनुमान न लगाएँ — यह स्प्रिंट में त्रुटियों की गारंटी है। चरण 4: परिणाम रिकॉर्ड करना (10 मिनट)। PO Jira/Linear में अनुमान रिकॉर्ड करता है, कार्य विवरण अपडेट करता है और प्राथमिकताएँ निर्धारित करता है।

ग्रूमिंग के परिणाम: Sprint Planning के लिए 3–7 पूरी तरह से तैयार कार्य (DoR, अनुमान, डिज़ाइन, API के साथ)। PO बैकलॉग अपडेट करता है: पुराने कार्यों को हटाता है, डुप्लिकेट को मर्ज करता है और प्राथमिकताओं को परिष्कृत करता है। महत्वपूर्ण: ग्रूमिंग PO का काम समाप्त नहीं करता — ग्रूमिंग सत्रों के बीच, PO को अगले कार्य तैयार करने चाहिए। अनुशंसित गति: PO ग्रूमिंग के लिए 3–4 कार्य तैयार करता है, और टीम उन पर काम करती है। यदि बैकलॉग में 50 से अधिक कार्य हैं, तो PO को ग्रूमिंग से पहले प्राथमिकता निर्धारण (MoSCoW या Weighted Shortest Job First) करना चाहिए।

ग्रूमिंग और Sprint Planning में अंतर

ग्रूमिंग — तैयारी है। इसमें कोई प्रतिबद्धता नहीं है — कार्य को केवल स्पष्ट और अनुमानित किया जाता है। Sprint Planning — एक प्रतिबद्धता है। टीम ग्रूमिंग में तैयार किए गए कार्यों में से चयन करती है और उन्हें स्प्रिंट के भीतर पूरा करने की प्रतिबद्धता लेती है। मुख्य अंतर: ग्रूमिंग किसी विशिष्ट स्प्रिंट से बंधा नहीं है (समग्र रूप से बैकलॉग परिशोधन), ग्रूमिंग के दौरान कोई Sprint Goal नहीं होता, और ग्रूमिंग स्प्रिंट के किसी भी समय आयोजित किया जा सकता है। Sprint Planning सख्ती से स्प्रिंट की शुरुआत में होता है और हमेशा Sprint Goal में परिणत होता है।

ग्रूमिंग में, कार्य केवल अनुमानित किए जाते हैं, लेकिन स्प्रिंट में नहीं लिए जाते। Planning में, कार्य तैयार पूल से चुने जाते हैं। ग्रूमिंग के बिना, Sprint Planning में 6–8 घंटे लगते हैं (4 के बजाय), क्योंकि टीम पहली बार कार्यों को देखती है और जल्दी से उनका अनुमान नहीं लगा सकती। 80/20 नियम: Sprint Planning पर 80% कार्य पूरी तरह से तैयार होने चाहिए (ग्रूमिंग से गुज़रे हुए), 20% नए हो सकते हैं (अत्यावश्यक बग, हॉटफ़िक्स)। यदि Planning पर 20% से अधिक कार्य बिना अनुमान के हैं — ग्रूमिंग अपर्याप्त था।

ग्रूमिंग की सामान्य गलतियाँ

गलती 1: महीने में एक बार ग्रूमिंग। टीम 3–4 स्प्रिंट के कार्य जमा करती है और 2 घंटे में सब कुछ परिष्कृत करने का प्रयास करती है। परिणाम: आधे कार्य बिना अनुमान के रह जाते हैं, और Planning पूरा दिन लेता है। समाधान: ग्रूमिंग नियमित होना चाहिए — प्रति स्प्रिंट एक बार, 60 मिनट। यदि कई कार्य हैं — स्प्रिंट के बीच में दूसरा ग्रूमिंग जोड़ें। कम कार्यों को गुणवत्तापूर्वक ग्रूम करना बेहतर है बजाय कई को सतही रूप से। गति: प्रति ग्रूमिंग सत्र 3–5 कार्य, प्रत्येक पूर्ण चर्चा और अनुमान प्राप्त करता है।

गलती 2: संदर्भ के बिना अनुमान। PO बिना डिज़ाइन, API या AC के “शॉपिंग कार्ट स्क्रीन लागू करें” कार्य प्रस्तुत करता है। टीम “आँख से” अनुमान लगाती है — 13 SP। Planning में पता चलता है कि यह वास्तव में 5 SP है (क्योंकि स्क्रीन सरल है)। समाधान: यदि डिज़ाइन या API नहीं है तो कार्य का अनुमान नहीं लगाया जाता। PO को ग्रूमिंग से पहले सामग्री तैयार करनी चाहिए। नियम: “कोई मॉकअप नहीं — कोई अनुमान नहीं”। अपवाद: Spike कार्य — अनिश्चितता अनुसंधान, उनका अनुमान बिना डिज़ाइन के अलग से लगाया जाता है (अनुसंधान जटिलता के आधार पर 2–5 SP)।

गलती 3: ग्रूमिंग Planning में बदल जाता है। टीम व्यक्तियों को कार्य सौंपना शुरू कर देती है और चर्चा करती है कि कौन क्या करेगा। समाधान: याद दिलाएँ कि ग्रूमिंग स्पष्टीकरण के लिए है, असाइनमेंट के लिए नहीं। असाइनमेंट — स्प्रिंट शुरू होने के बाद Daily में होता है। ग्रूमिंग उत्तर देता है “क्या करना है?”, Planning उत्तर देता है “कब करना है?”, Daily उत्तर देता है “कौन कर रहा है?” एक बैठक में इन प्रश्नों को मिलाने से प्रत्येक की प्रभावशीलता कम हो जाती है। Scrum Master को Planning जैसी चर्चाओं को रोकना चाहिए और ध्यान कार्य स्पष्टीकरण पर पुनर्निर्देशित करना चाहिए।

गलती 4: Tech Debt को अनदेखा करना। ग्रूमिंग में केवल नई सुविधाओं पर चर्चा की जाती है, तकनीकी कार्यों को अनदेखा किया जाता है। 3–4 स्प्रिंट के बाद, तकनीकी ऋण एक महत्वपूर्ण स्तर तक जमा हो जाता है। समाधान: प्रत्येक ग्रूमिंग में, कम से कम 1 तकनीकी कार्य का अनुमान लगाया जाना चाहिए। अनुपात: प्रत्येक 3 सुविधाओं पर → 1 तकनीकी कार्य। Tech Debt Ratio मीट्रिक का उपयोग करें: स्प्रिंट में तकनीकी कार्यों और सुविधा कार्यों का अनुपात। लक्ष्य मान: 0.25–0.3 (तकनीकी ऋण पर 25–30% समय)। यदि अनुपात 0.2 से कम है — अगले स्प्रिंट में डेवलपमेंट वेग कम हो जाएगा।