Agile में सापेक्ष अनुमान: घंटों के बिना कार्य का आकार निर्धारित करने की संपूर्ण गाइड

सापेक्ष अनुमान एक ऐसी तकनीक है जिसमें टीमें कार्य आइटमों का आकार घंटों या दिनों जैसी पूर्ण इकाइयों में अनुमान लगाने के बजाय, उन्हें एक-दूसरे से तुलना करके निर्धारित करती हैं। "इसमें कितना समय लगेगा?" पूछने के बजाय, टीमें पूछती हैं "क्या यह उस दूसरे काम से बड़ा है या छोटा जो हमने किया था?" सोच में यह बदलाव Agile में सबसे शक्तिशाली - और सबसे अधिक गलत समझी जाने वाली - अवधारणाओं में से एक है। जो टीमें सापेक्ष अनुमान अपनाती हैं, वे लगातार अधिक सटीक पूर्वानुमान देती हैं, अनुमान लगाने में कम समय लगाती हैं, और छिपे हुए जोखिमों को जल्दी उजागर करती हैं। यह गाइड बताती है कि सापेक्ष अनुमान क्यों काम करता है, कौन सी तकनीकें उपलब्ध हैं, इसे कैसे लागू करें, और कौन सी गलतियां टीमों को पटरी से उतारती हैं।

त्वरित उत्तर: सापेक्ष बनाम पूर्ण अनुमान

पहलू	सापेक्ष अनुमान	पूर्ण अनुमान
आप क्या अनुमान लगाते हैं	अन्य कार्य आइटमों की तुलना में आकार	घंटे, दिन, या कैलेंडर समय
मूल प्रश्न	"क्या यह X से बड़ा है या छोटा?"	"इसमें कितने घंटे लगेंगे?"
माप की इकाई	Story Points, T-shirt sizes, या बकेट	घंटे, दिन, या व्यक्ति-दिन
सटीकता	जानबूझकर मोटी (जैसे, Fibonacci स्केल)	झूठी सटीक ("बिल्कुल 14 घंटे")
व्यक्ति-निर्भर	नहीं - टीम मिलकर अनुमान लगाती है	हां - कौन काम करता है उस पर निर्भर
समय के साथ सटीकता	बेहतर होती है जैसे टीम Velocity कैलिब्रेट करती है	अभ्यास के बावजूद असंगत रहती है
सर्वोत्तम उपयोग	Sprint Planning, रिलीज़ पूर्वानुमान, बैकलॉग आकलन	Story के भीतर कार्य विभाजन, समय ट्रैकिंग

सापेक्ष अनुमान क्या है?

मूल अंतर्दृष्टि

सापेक्ष अनुमान पूर्ण समय मान निर्दिष्ट करने के बजाय आइटमों की एक-दूसरे से तुलना करके कार्य का आकार निर्धारित करने की प्रथा है। जब कोई टीम सापेक्ष अनुमान का उपयोग करती है, तो वे नहीं पूछते "इस story में कितने घंटे लगेंगे?" वे पूछते हैं "यह story उन stories की तुलना में कैसी है जिनका हमने पहले आकलन किया या जो हमने पूरी की हैं?"

आउटपुट एक सापेक्ष आकार होता है - एक संख्या, एक लेबल, या एक श्रेणी जो आइटम को Product Backlog में बाकी सबकी तुलना में एक स्केल पर रखती है। 8 पॉइंट पर अनुमानित story "8 घंटे" या "8 दिन" नहीं है - इसका मतलब है "यह story हमारी 5-पॉइंट संदर्भ story से लगभग 8/5 गुना बड़ी है।"

एक सरल उदाहरण

कल्पना करें कि आप पत्थरों के एक ढेर को वज़न के अनुसार छांट रहे हैं। आपके पास दो विकल्प हैं:

1. पूर्ण दृष्टिकोण: प्रत्येक पत्थर को तराज़ू पर तौलें, ग्राम लिखें, और संख्या के अनुसार छांटें।
2. सापेक्ष दृष्टिकोण: दो पत्थर उठाएं - एक प्रत्येक हाथ में - और महसूस करें कौन भारी है। अन्य पत्थरों के साथ दोहराएं जब तक कि वे हल्के से भारी क्रम में न आ जाएं।

सापेक्ष दृष्टिकोण तेज़ है, किसी उपकरण की आवश्यकता नहीं है, और एक उपयोगी रैंकिंग देता है। आप प्रत्येक पत्थर का सटीक वज़न नहीं जानते, लेकिन आप आत्मविश्वास से कह सकते हैं कि पत्थर C, पत्थर A से लगभग दोगुना भारी है। नियोजन उद्देश्यों के लिए - "क्या मैं इन पत्थरों को एक बार में ले जा सकता हूं?" - सापेक्ष तुलना आमतौर पर पर्याप्त होती है।

सॉफ्टवेयर अनुमान भी इसी तरह काम करता है। आपको शायद ही कभी सटीक घंटे जानने की आवश्यकता होती है। आपको सापेक्ष आकार जानने की आवश्यकता होती है ताकि आप उत्तर दे सकें: "क्या हम इस काम को अगले Sprint में फिट कर सकते हैं?"

सापेक्ष अनुमान पूर्ण अनुमान से बेहतर क्यों काम करता है

मनोविज्ञान: Weber-Fechner Law

Weber-Fechner Law, जो 19वीं शताब्दी में स्थापित हुआ, बताता है कि मनुष्य उत्तेजनाओं में अंतर को पूर्ण रूप से नहीं बल्कि अनुपातिक रूप से अनुभव करते हैं। आप आसानी से 1 किलो और 2 किलो वज़न उठाने के बीच अंतर बता सकते हैं (100% अंतर)। लेकिन 50 किलो और 51 किलो वज़न के बीच अंतर (2% अंतर) बताना बहुत कठिन है, भले ही दोनों अंतर बिल्कुल 1 किलो हैं।

यह नियम बताता है कि Fibonacci sequence अनुमान के लिए इतनी अच्छी क्यों काम करती है। मूल्यों के बीच अंतराल अनुपातिक रूप से बढ़ते हैं: 1-2-3-5-8-13-21। प्रत्येक संख्या पिछली से लगभग 60% बड़ी है। यह दर्शाता है कि हमारा मस्तिष्क वास्तव में परिमाण को कैसे संसाधित करता है - हम अनुपातिक अंतर पहचानते हैं, पूर्ण अंतर नहीं।

जब टीमें घंटों में अनुमान लगाती हैं, तो उन्हें पूर्ण निर्णय लेने के लिए मजबूर किया जाता है जिसके लिए उनका मस्तिष्क बना नहीं है। जब वे बढ़ते अंतरालों के साथ सापेक्ष आकारों में अनुमान लगाती हैं, तो वे अपनी संज्ञानात्मक शक्तियों के साथ काम करती हैं, विरुद्ध नहीं।

संज्ञानात्मक विज्ञान: तुलना बनाम भविष्यवाणी

संज्ञानात्मक मनोविज्ञान में शोध लगातार दिखाता है कि मनुष्य भविष्यवाणी करने की तुलना में तुलना करने में बहुत बेहतर हैं:

• तुलना (सापेक्ष): "क्या इस API endpoint को बनाना पिछले Sprint में बनाए गए लॉगिन फ़ीचर से बड़ा है या छोटा?" आपका मस्तिष्क एक ठोस स्मृति याद करता है और त्वरित तुलना करता है। यह पहचान स्मृति को सक्रिय करता है, जो तेज़ और विश्वसनीय है।
• भविष्यवाणी (पूर्ण): "इस API endpoint में कितने घंटे लगेंगे?" आपके मस्तिष्क को कार्य के पूरे भविष्य के निष्पादन का अनुकरण करना होता है - हर एज केस, हर रुकावट, हर अज्ञात। यह रचनात्मक कल्पना को सक्रिय करता है, जो धीमी और अविश्वसनीय है।

जो टीमें घंटों से सापेक्ष अनुमान में बदलती हैं, वे आमतौर पर 4-6 Sprints के भीतर अपनी पूर्वानुमान सटीकता में सुधार देखती हैं क्योंकि वे अपनी संज्ञानात्मक संरचना से लड़ना बंद कर देती हैं।

एंकरिंग का लाभ

सापेक्ष अनुमान टीमों को एक ठोस एंकर देता है - एक संदर्भ story - जो अनुमान को तेज़ और अधिक सुसंगत बनाती है। एंकर के बिना, प्रत्येक अनुमान सत्र शून्य से शुरू होता है: "तो... क्या यह 16 घंटे है?" एक संदर्भ story के साथ, बातचीत ठोस आधार पर होती है: "हमारी 5-पॉइंट संदर्भ story यूज़र प्रोफ़ाइल API थी। यह नई story जटिलता में समान है लेकिन तृतीय-पक्ष एकीकरण से अधिक अनिश्चितता है, तो यह शायद 8 है।"

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

अनिश्चितता को अवशोषित करना

पूर्ण अनुमान झूठी सटीकता का दबाव बनाते हैं। "14 घंटे" कहना यह दर्शाता है कि आप कार्य की अवधि को उस सटीकता के स्तर तक जानते हैं जो सॉफ्टवेयर विकास शायद ही कभी प्रदान करता है। जब वह 14 घंटे का अनुमान 22 घंटे हो जाता है, तो यह विफलता जैसा लगता है।

सापेक्ष अनुमान डिज़ाइन द्वारा अनिश्चितता को स्वीकार करता है। "यह उस 8-पॉइंट story जितना ही बड़ा है" कहना स्वीकार करता है कि आप सटीक घंटे नहीं जानते - और आपको जानने की ज़रूरत नहीं है। Fibonacci स्केल के बढ़ते अंतराल जानबूझकर झूठी सटीकता को रोकते हैं: आप "यह 6 है" नहीं कह सकते जब आपके विकल्प 5 या 8 हैं, और यह मोटापन एक विशेषता है, दोष नहीं।

संदर्भ Story दृष्टिकोण

अपनी बेसलाइन चुनना

संदर्भ story एक अच्छी तरह से समझा गया, पूर्ण किया गया काम है जिसे टीम भविष्य के सभी अनुमानों के लिए बेंचमार्क के रूप में उपयोग करती है। सही संदर्भ story चुनना महत्वपूर्ण है - यह वह पैमाना बन जाती है जिसके विरुद्ध बाकी सबको मापा जाता है।

अच्छी संदर्भ story की विशेषताएं:

• टीम ने इसे हाल ही में पूरा किया है ताकि विवरण याद हों
• यह एक मध्यम आकार का काम था (न सबसे छोटा, न सबसे बड़ा)
• प्रयास, जटिलता और अनिश्चितता सभी मध्यम थे
• अधिकांश टीम सदस्यों ने इस पर काम किया या इससे परिचित हैं
• यह टीम के लिए एक सामान्य प्रकार के काम का प्रतिनिधित्व करती है

अपनी संदर्भ story को अपने स्केल के मध्य में एक मान दें - आमतौर पर Fibonacci स्केल पर 3 या 5।

संदर्भ सूची बनाना

एक अकेली संदर्भ story पर्याप्त नहीं है। 5-7 संदर्भ stories की एक सूची बनाएं जो आपके अनुमान स्केल को कवर करे:

पॉइंट	संदर्भ Story	यह आकार क्यों
1	मौजूदा बटन पर टूलटिप जोड़ना	न्यूनतम प्रयास, कोई जटिलता नहीं, कोई अनिश्चितता नहीं
2	मौजूदा फ़ॉर्म फ़ील्ड पर इनपुट सत्यापन जोड़ना	छोटा प्रयास, कम जटिलता, कोई अनिश्चितता नहीं
3	मानक CRUD के साथ नया API endpoint बनाना	मध्यम प्रयास, कम जटिलता, न्यूनतम अनिश्चितता
5	API एकीकरण के साथ यूज़र प्रोफ़ाइल पेज बनाना	महत्वपूर्ण प्रयास, मध्यम जटिलता, कुछ अनिश्चितता
8	तृतीय-पक्ष भुगतान गेटवे एकीकरण	बड़ा प्रयास, उच्च जटिलता, उल्लेखनीय अनिश्चितता
13	रीयल-टाइम पुश के साथ नोटिफ़िकेशन सिस्टम का पुनर्डिज़ाइन	बहुत बड़ा प्रयास, उच्च जटिलता, महत्वपूर्ण अनिश्चितता

हर तिमाही या जब टीम संरचना में महत्वपूर्ण बदलाव हो तो इस सूची की समीक्षा और अपडेट करें। नए टीम सदस्यों को अपने पहले अनुमान सत्र से पहले इन संदर्भ stories का अध्ययन करना चाहिए।

समय के साथ कैलिब्रेशन

सापेक्ष अनुमान कैलिब्रेशन के माध्यम से बेहतर होता है - अनुमानों की वास्तविक परिणामों से तुलना और समायोजन की प्रक्रिया:

1. Sprint Retrospective समीक्षा: "हमने इसे 5 पॉइंट का अनुमान लगाया लेकिन यह स्पष्ट रूप से 8 था - हमने क्या चूका?"
2. पैटर्न पहचान: "हम डेटाबेस माइग्रेशन वाली stories को लगातार लगभग एक Fibonacci स्तर कम आंकते हैं।"
3. संदर्भ अपडेट: "हमारी 5-पॉइंट संदर्भ story अब नहीं दर्शाती कि 5 कैसा महसूस होता है। आइए एक बेहतर चुनें।"

यह कैलिब्रेशन लूप वह इंजन है जो सापेक्ष अनुमान को समय के साथ तेज़ी से सटीक बनाता है। जो टीमें कैलिब्रेशन छोड़ देती हैं, वे शोर वाले अनुमानों में अटकी रहती हैं जो कभी सुधरते नहीं।

सापेक्ष अनुमान तकनीकें

Story Points

Story Points सबसे व्यापक रूप से उपयोग की जाने वाली सापेक्ष अनुमान इकाई हैं। प्रत्येक Story Point प्रयास, जटिलता और अनिश्चितता के मिश्रण का प्रतिनिधित्व करता है - एक सापेक्ष स्केल पर एकल संख्या के रूप में व्यक्त।

मुख्य विशेषताएं:

• टीम-विशिष्ट: टीम A पर एक 5-पॉइंट story टीम B पर 5-पॉइंट story के समान नहीं है
• स्केल-आधारित: आमतौर पर Fibonacci (1, 2, 3, 5, 8, 13, 21) या संशोधित Fibonacci का उपयोग करता है
• Velocity-संबद्ध: प्रति Sprint पूर्ण कुल Story Points = Velocity
• घंटों में रूपांतरित नहीं: कोई वैध Story-Point-से-घंटे रूपांतरण नहीं है

Story Points Sprint-स्तर नियोजन और रिलीज़ पूर्वानुमान के लिए आदर्श हैं। उन्हें संदर्भ stories, कैलिब्रेशन और टीम सुसंगतता में निवेश की आवश्यकता होती है - लेकिन प्रतिफल 4-6 Sprints के भीतर विश्वसनीय Velocity डेटा है।

T-Shirt Sizing

T-shirt sizing संख्याओं के बजाय लेबल का उपयोग करता है: XS, S, M, L, XL, XXL। यह सापेक्ष अनुमान का सबसे सुलभ रूप है क्योंकि हर कोई सहज रूप से समझता है कि "Large", "Small" से बड़ा है।

सर्वोत्तम उपयोग:

• प्रारंभिक बैकलॉग आकलन जब आपके पास 50-200 आइटम तेज़ी से अनुमान लगाने हों
• रोडमैप-स्तर नियोजन जहां सटीकता की आवश्यकता नहीं
• सापेक्ष अनुमान में नई टीमें जो संख्याओं से डरती हैं
• Stakeholder संचार (Story Points से समझाना आसान)

सीमा: T-shirt sizes Velocity में एकत्रित नहीं होते। आप "2 Mediums और 1 Large" जोड़कर क्षमता संख्या नहीं पा सकते। कई टीमें T-shirt sizing से शुरू करती हैं और सापेक्ष सोच में सहज होने पर Story Points में बदल जाती हैं।

Fibonacci Sequence Scale

Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) सापेक्ष अनुमान के लिए सबसे सामान्य स्केल है क्योंकि इसके बढ़ते अंतराल मानव अनुभूति के काम करने के तरीके को दर्शाते हैं। यह sequence अनुमानकर्ताओं को छोटे छोर पर सार्थक भेद करने के लिए मजबूर करती है (क्या यह 2 है या 3?) जबकि बड़े छोर पर झूठी सटीकता को रोकती है (13 और 21 के बीच कोई विकल्प नहीं है)।

Fibonacci अनुमान के लिए क्यों काम करती है:

• अंतराल वृद्धि Weber-Fechner Law के ह्रासमान अनुभूति को दर्शाती है
• अर्थहीन अंतरों पर बहस रोकती है ("क्या यह 14 है या 15?")
• 13 से ऊपर की stories को विभाजित करने के लिए मजबूर करती है - बड़े आइटम में बहुत अधिक अनिश्चितता होती है
• प्रत्येक मान पिछले से लगभग 60% बड़ा है, जो सुसंगत अनुपातिक छलांग बनाता है

कुछ टीमें संशोधित Fibonacci (1, 2, 3, 5, 8, 13, 20, 40, 100) का उपयोग करती हैं जो 21 को आसान मानसिक गणित के लिए 20 से बदलती है और विभाजन की आवश्यकता वाले बैकलॉग आइटमों के लिए 40 और 100 जोड़ती है।

Affinity Estimation

Affinity estimation बड़ी संख्या में आइटमों को तेज़ी से आकार देने की तकनीक है। टीम भौतिक या आभासी रूप से आइटमों को सापेक्ष आकार श्रेणियों में समूहित करती है, उनकी एक-दूसरे से तुलना करके - प्रत्येक पर विस्तार से चर्चा किए बिना।

यह कैसे काम करता है:

1. स्केल बिछाएं (1, 2, 3, 5, 8, 13 लेबल वाले कॉलम)
2. पहला आइटम शुरुआती संदर्भ के रूप में मध्य कॉलम में रखें
3. टीम सदस्य चुपचाप शेष आइटमों को सापेक्ष आकार के आधार पर कॉलमों में रखें
4. समूहों की समीक्षा करें, असहमतियों पर चर्चा करें, और समायोजित करें

गति लाभ: Affinity estimation 30-60 मिनट में 50-100 आइटमों का आकार निर्धारित कर सकता है - समान संख्या के आइटमों के लिए Planning Poker से 10 गुना तेज़।

सर्वोत्तम उपयोग: बड़े बैकलॉग का प्रारंभिक आकलन, स्केल्ड फ्रेमवर्क में PI नियोजन, और कोई भी स्थिति जहां आपको कई आइटमों के लिए तेज़ी से मोटे अनुमान चाहिए।

Planning Poker

Planning Poker विस्तृत सापेक्ष अनुमान के लिए स्वर्ण मानक है। प्रत्येक Developer एंकरिंग पूर्वाग्रह को रोकते हुए एक साथ अपने अनुमान वाला कार्ड चुनता है। जब अनुमान भिन्न होते हैं, तो टीम चर्चा करती है - और ये चर्चाएं अक्सर प्रक्रिया का सबसे मूल्यवान हिस्सा होती हैं।

यह कैसे काम करता है:

1. Product Owner story प्रस्तुत करता है और प्रश्नों का उत्तर देता है
2. प्रत्येक Developer निजी तौर पर एक Fibonacci कार्ड चुनता है
3. सभी कार्ड एक साथ प्रकट किए जाते हैं
4. यदि अनुमान एकमत हैं (जैसे, सभी 5 या 8 दिखाते हैं), सहमति जल्दी बन जाती है
5. यदि अनुमान भिन्न हैं (जैसे, एक 3 और दूसरा 13 दिखाता है), चरम अनुमान वाले अपना तर्क बताते हैं
6. चर्चा के बाद पुनः मतदान, आमतौर पर 2-3 राउंड में सहमति बन जाती है

सर्वोत्तम उपयोग: Sprint-स्तर की 5-15 आइटमों का परिष्करण जहां विस्तृत चर्चा और जोखिम पहचान महत्वपूर्ण हो।

सापेक्ष अनुमान कैसे लागू करें: चरण-दर-चरण

चरण 1: अपनी तकनीक चुनें

वह तकनीक चुनें जो आपकी वर्तमान आवश्यकता से मेल खाती हो:

स्थिति	अनुशंसित तकनीक
नई टीम, पहली बार अनुमान लगा रही है	T-shirt sizing (प्रवेश में कम बाधा)
बड़े बैकलॉग को प्रारंभिक आकलन चाहिए (50+ आइटम)	Affinity estimation
Sprint-स्तर परिष्करण (5-15 आइटम)	Story Points के साथ Planning Poker
रोडमैप या PI नियोजन	T-shirt sizing या Affinity estimation
परिपक्व टीम, स्थिर बैकलॉग	त्वरित सहमति के साथ Story Points

चरण 2: संदर्भ Stories स्थापित करें

अपने पहले अनुमान सत्र से पहले, 3-5 पूर्ण stories पहचानें जो आपके स्केल को कवर करती हैं। उन्हें टीम के सामने प्रस्तुत करें और उनके सापेक्ष आकारों पर सहमत हों। उन्हें लिख लें - ये हर भविष्य के सत्र के लिए आपका कैलिब्रेशन एंकर बन जाती हैं।

चरण 3: अपना पहला सत्र चलाएं

Planning Poker के लिए:

• संदर्भ stories को बोर्ड या साझा स्क्रीन पर दृश्यमान रखकर शुरू करें
• प्रत्येक नई story प्रस्तुत करें, कार्यक्षेत्र और स्वीकृति मानदंड पर प्रश्नों की अनुमति दें
• प्रत्येक Developer से निजी तौर पर कार्ड चुनवाएं, फिर एक साथ प्रकट करें
• भिन्नता पर चर्चा करें, फिर पुनः मतदान करें
• प्रति story 2-5 मिनट का लक्ष्य रखें - यदि सहमति नहीं बन पाती, तो बड़ा अनुमान चुनें और आगे बढ़ें

Affinity Estimation के लिए:

• स्केल कॉलम बिछाएं
• प्रत्येक कॉलम में एक संदर्भ story रखें
• टीम सदस्यों से चुपचाप शेष stories रखवाएं
• समूहों की समीक्षा करें, चर्चा करें और समायोजित करें
• प्रति story 10-20 सेकंड का लक्ष्य रखें

चरण 4: Velocity ट्रैक करें (यदि Story Points उपयोग कर रहे हैं)

प्रत्येक Sprint के बाद, पूर्ण कुल Story Points दर्ज करें (केवल Definition of Done पूरा करने वाली stories)। 4-6 Sprints के बाद, आपके पास विश्वसनीय Velocity-आधारित पूर्वानुमान के लिए पर्याप्त डेटा होगा।

चरण 5: Retrospectives में कैलिब्रेट करें

प्रत्येक Sprint Retrospective में, अनुमान सटीकता की समीक्षा के लिए 5 मिनट दें:

• क्या कोई stories अनुमान से काफी बड़ी या छोटी निकलीं?
• आश्चर्य का कारण क्या था?
• क्या किसी संदर्भ story को अपडेट किया जाना चाहिए?
• क्या कोई व्यवस्थित पैटर्न हैं (जैसे, "हम हमेशा एकीकरण कार्य को कम आंकते हैं")?

चरण 6: अपना स्केल परिष्कृत करें

6-10 Sprints के बाद, मूल्यांकन करें कि आपका स्केल अभी भी काम कर रहा है या नहीं:

• यदि सब कुछ 3-5 पर क्लस्टर होता है, तो आपकी संदर्भ stories बहुत मोटी हो सकती हैं
• यदि आप नियमित रूप से 13+ मानों का उपयोग कर रहे हैं, तो आपकी टीम को अधिक आक्रामक रूप से विभाजित करने की आवश्यकता हो सकती है
• यदि Velocity अस्थिर है, तो जांचें कि अनुमान सुसंगतता या बाहरी कारक इसका कारण हैं

चरण 7: नियोजन के साथ एकीकृत करें

एक बार Velocity स्थिर हो जाए (विचरण गुणांक 25% से कम), इसका उपयोग करें:

• Sprint Planning: Story Points में लगभग एक Sprint की Velocity जितना कार्य चुनें
• रिलीज़ नियोजन: शेष बैकलॉग पॉइंट को औसत Velocity से विभाजित करें ताकि पूर्णता का पूर्वानुमान लगा सकें
• क्षमता नियोजन: संभाव्य पूर्वानुमान के लिए Velocity रेंज (सर्वोत्तम/औसत/सबसे खराब) का उपयोग करें

सापेक्ष बनाम पूर्ण अनुमान: विस्तृत तुलना

आयाम	सापेक्ष अनुमान	पूर्ण अनुमान
संज्ञानात्मक भार	कम - पैटर्न मिलान और तुलना	अधिक - भविष्य के निष्पादन का अनुकरण आवश्यक
गति	तेज़ - अधिकांश आइटम 1-3 मिनट में अनुमानित	धीमी - विस्तृत कार्य विघटन आवश्यक
सटीकता (व्यक्तिगत आइटम)	कम - कोई भी एकल अनुमान एक Fibonacci स्तर तक गलत हो सकता है	मध्यम - परिचित कार्य के लिए घंटे का अनुमान करीब हो सकता है
सटीकता (समग्र)	उच्च - Sprint में अधिक/कम अनुमान एक-दूसरे को रद्द करते हैं	कम - त्रुटियां रद्द होने के बजाय संयोजित होती हैं
टीम बनाम व्यक्ति	टीम-आधारित - व्यक्तिगत पूर्वाग्रह कम करता है	अक्सर व्यक्तिगत - एक व्यक्ति का अनुमान
अनिश्चितता संभालना	अच्छा - मोटा स्केल अज्ञातों को अवशोषित करता है	खराब - झूठी सटीकता का दबाव
सीखने की अवस्था	मध्यम - कैलिब्रेट करने में 4-6 Sprints लगते हैं	कम - हर कोई घंटे समझता है
रखरखाव	संदर्भ stories और कैलिब्रेशन आवश्यक	कार्यक्षेत्र बदलने पर पुनः अनुमान आवश्यक
क्रॉस-टीम तुलना	संभव नहीं (टीम-विशिष्ट इकाइयां)	संभव लेकिन भ्रामक (अलग-अलग क्षमताएं)
Stakeholder संचार	Velocity के माध्यम से तिथियों में अनुवाद आवश्यक	सीधा लेकिन अक्सर गलत

सापेक्ष बनाम पूर्ण अनुमान कब उपयोग करें

सापेक्ष अनुमान कब उपयोग करें:

• जब आपको Sprint-स्तर या रिलीज़-स्तर पूर्वानुमान चाहिए
• जब टीम परिष्करण के दौरान Product Backlog में कार्य का आकलन कर रही हो
• जब कार्य आइटम आकार में काफी भिन्न हों
• जब आप टीम चर्चा के माध्यम से जोखिमों और गलतफहमियों को उजागर करना चाहें
• जब आपको कई आइटमों में समग्र सटीकता चाहिए

पूर्ण अनुमान कब उपयोग करें:

• जब आप Sprint Planning के दौरान story को कार्यान्वयन कार्यों में तोड़ रहे हों
• जब काम अत्यधिक परिचित और पूर्वानुमान योग्य हो (जैसे, "इस माइग्रेशन स्क्रिप्ट में 2 घंटे लगते हैं")
• जब अनुबंध दायित्वों को समय-आधारित अनुमान की आवश्यकता हो
• जब आप बिलिंग या अनुपालन उद्देश्यों के लिए बिताए गए समय को ट्रैक कर रहे हों
• जब व्यक्तिगत कार्य असाइनमेंट को समय सीमाओं की आवश्यकता हो

कई टीमें दोनों का उपयोग करती हैं: story-स्तर आकलन के लिए सापेक्ष अनुमान (Sprint Planning और पूर्वानुमान के लिए Story Points) और कार्य-स्तर नियोजन के लिए पूर्ण अनुमान (Sprint के भीतर व्यक्तिगत कार्य संगठन के लिए घंटे)।

उद्योग उदाहरण

SaaS उत्पाद विकास

7 डेवलपर्स वाली एक SaaS टीम Sprint परिष्करण के लिए Fibonacci स्केल पर Story Points और Planning Poker का उपयोग करती है। उनकी संदर्भ stories: 1-पॉइंट कॉन्फ़िग परिवर्तन, 3-पॉइंट फ़ीचर सुधार, 5-पॉइंट API एकीकरण वाले नए फ़ीचर, 8-पॉइंट तृतीय-पक्ष सेवा एकीकरण। वे 2-सप्ताह के Sprints चलाते हैं जिनकी स्थिर Velocity 34 पॉइंट है, जिससे वे 1 Sprint की सटीकता के भीतर त्रैमासिक रिलीज़ का पूर्वानुमान लगा सकते हैं।

स्वास्थ्य सेवा सॉफ्टवेयर

EHR एकीकरण सॉफ्टवेयर बनाने वाली एक स्वास्थ्य सेवा टीम अपने सापेक्ष अनुमानों में नियामक अनुपालन शामिल करती है। PHI (संरक्षित स्वास्थ्य जानकारी) वाली stories स्वचालित रूप से समकक्ष गैर-PHI stories से 1-2 Fibonacci स्तर ऊपर आकार की जाती हैं क्योंकि HIPAA दस्तावेज़ीकरण, ऑडिट लॉगिंग, एन्क्रिप्शन सत्यापन और सुरक्षा समीक्षा आवश्यक है। उनकी Velocity (22 पॉइंट प्रति Sprint) गैर-विनियमित टीमों से कम है, लेकिन पूर्वानुमान सटीक हैं क्योंकि अनुपालन प्रयास सापेक्ष आकारों में समाहित है।

वित्तीय सेवाएं

भुगतान प्रसंस्करण सुविधाओं का अनुमान लगाने वाली एक fintech टीम stakeholders के साथ प्रारंभिक रोडमैप चर्चाओं के लिए T-shirt sizing का उपयोग करती है (S/M/L 1-महीने/1-तिमाही/बहु-तिमाही डिलीवरी से मैप होता है) और Sprint-स्तर कार्य के लिए Story Points में बदलती है। PCI-DSS अनुपालन आवश्यकताएं उनकी संदर्भ stories में समाहित हैं - एक "5-पॉइंट भुगतान फ़ीचर" में स्वाभाविक रूप से वह अनुपालन परीक्षण शामिल है जो टीम ने सीखा है कि हर भुगतान-संबंधी परिवर्तन के साथ आता है।

ई-कॉमर्स प्लेटफ़ॉर्म

एक ई-कॉमर्स टीम तीन कार्य प्रकारों में सापेक्ष अनुमानों को ट्रैक करती है: ग्राहक-सामने वाले फ़ीचर, प्रदर्शन अनुकूलन, और इन्फ्रास्ट्रक्चर। वे प्रत्येक प्रकार के लिए अलग संदर्भ सूची बनाए रखती हैं क्योंकि प्रयास/जटिलता/अनिश्चितता प्रोफ़ाइल काफी भिन्न हैं। एक 5-पॉइंट ग्राहक फ़ीचर में UI कार्य और API एकीकरण शामिल है, जबकि एक 5-पॉइंट इन्फ्रास्ट्रक्चर परिवर्तन में Terraform मॉड्यूल और मॉनिटरिंग सेटअप शामिल है। अलग सूची क्रॉस-टाइप अनुमान बहाव को रोकती है।

सरकारी सॉफ्टवेयर

एक सरकारी ठेकेदार टीम निश्चित-मूल्य अनुबंधों की सीमाओं के भीतर सापेक्ष अनुमान का उपयोग करती है। वे कुल Story Point गणना प्राप्त करने के लिए Affinity estimation से प्रारंभिक बैकलॉग का अनुमान लगाते हैं, Sprint संख्या का अनुमान लगाने के लिए अनुमानित Velocity से विभाजित करते हैं, और Sprint गणना (विश्वास सीमा सहित) अनुबंध अधिकारी को प्रस्तुत करते हैं। आंतरिक रूप से, वे Velocity ट्रैक करते हैं और Sprint Planning के लिए इसका उपयोग करते हैं। सापेक्ष अनुमान उन्हें घंटों में पुनः अनुमान लगाए बिना निश्चित बजट के भीतर पुनर्क्रम और पुनर्कार्यक्षेत्र करने की अनुमति देता है।

EdTech प्लेटफ़ॉर्म

एक लर्निंग मैनेजमेंट सिस्टम बनाने वाली EdTech टीम एक विशेषता के साथ सापेक्ष अनुमान का उपयोग करती है: वे सुगम्यता कार्य का अलग से आकलन करती हैं। हर फ़ीचर को दो अनुमान मिलते हैं - मूल कार्यक्षमता और सुगम्यता अनुपालन (WCAG 2.1 AA)। एक फ़ीचर मूल कार्यक्षमता के लिए 5 पॉइंट और सुगम्यता के लिए 3 पॉइंट हो सकता है, कुल 8 पॉइंट। यह दृश्यता Product Owner को सुगम्यता अनुपालन की लागत समझने और तदनुसार योजना बनाने में मदद करती है, बजाय इसे अदृश्य ओवरहेड मानने के।

सापेक्ष अनुमान परिपक्वता मॉडल

चरण 1: शुरुआत (Sprints 1-4)

विशेषताएं:

• टीम सापेक्ष अनुमान में नई है या घंटों से बदल रही है
• अनुमान मनमाने लगते हैं - "क्या यह 3 है या 5? मुझे कोई अंदाज़ा नहीं"
• अभी तक कोई Velocity डेटा नहीं
• संदर्भ stories स्थापित की जा रही हैं
• अनुमान सत्र लंबे चलते हैं (5-10 आइटमों के लिए 30+ मिनट)

ध्यान किस पर दें:

• 3-5 संदर्भ stories चुनें और हर सत्र के दौरान उन्हें भौतिक रूप से प्रदर्शित करें
• सटीकता की चिंता न करें - सुसंगतता पर ध्यान दें (हमेशा समान संदर्भों से तुलना करें)
• Velocity ट्रैक करें लेकिन नियोजन के लिए अभी इस पर निर्भर न रहें
• यदि Story Points शुरू में बहुत अमूर्त लगें तो T-shirt sizing का उपयोग करें

अपेक्षित परिणाम: Sprint 4 तक, टीम को अनुमानों पर तेज़ी से सहमत होना चाहिए और सापेक्ष स्केल के साथ सहज महसूस करना चाहिए।

चरण 2: कैलिब्रेशन (Sprints 5-10)

विशेषताएं:

• Velocity डेटा मौजूद है लेकिन शोर वाला (Sprints के बीच उच्च विचरण)
• टीम अनुमानों पर तेज़ी से सहमत होती है - अधिकांश आइटम 1-2 राउंड में सहमत
• कुछ stories अभी भी आश्चर्य देती हैं (अनुमान से बड़ी या छोटी)
• वास्तविक पूर्णता डेटा के आधार पर संदर्भ सूची परिष्कृत हो रही है
• अनुमान सत्र 5-10 आइटमों के लिए 15-20 मिनट लेते हैं

ध्यान किस पर दें:

• हर Retrospective में अनुमानों की तुलना वास्तविक परिणामों से करें
• व्यवस्थित पैटर्न पहचानें: "हम हमेशा [X] की आवश्यकता वाली stories को कम आंकते हैं"
• Sprint क्षमता नियोजन के लिए Velocity का उपयोग शुरू करें (बफर के साथ)
• जो सीखा है उसके आधार पर संदर्भ stories अपडेट करें

अपेक्षित परिणाम: Sprint 10 तक, Velocity विचरण घट रहा होना चाहिए और Sprint पूर्णता दर बढ़ रही होनी चाहिए।

चरण 3: विश्वसनीय (Sprints 11-20)

विशेषताएं:

• Velocity 15-20% सीमा के भीतर पूर्वानुमान योग्य
• अनुमान सत्र कुशल - 5-10 आइटमों के लिए 10-15 मिनट
• कैरी-ओवर दुर्लभ (प्रति Sprint 1 से कम story)
• टीम में सापेक्ष आकलन की सहज समझ
• संदर्भ सूची स्थिर और त्रैमासिक अपडेट

ध्यान किस पर दें:

• रिलीज़ पूर्वानुमान के लिए Velocity रेंज (सर्वोत्तम/औसत/सबसे खराब) का उपयोग करें
• संदर्भ सूची का उपयोग करके नए टीम सदस्यों को कोच करें
• पूर्णता पैटर्न के आधार पर अपनी विभाजन सीमा परिष्कृत करें
• क्रॉस-सत्यापन के लिए Velocity के साथ throughput ट्रैक करें

अपेक्षित परिणाम: 1-2 Sprints की सटीकता के भीतर विश्वसनीय रिलीज़ तिथि पूर्वानुमान।

चरण 4: अनुकूलित (Sprint 20+)

विशेषताएं:

• Velocity का विचरण गुणांक 15% से कम
• अनुमान में न्यूनतम समय लगता है - टीम अक्सर बिना चर्चा के सहमत
• पूर्वानुमान 10-15% के भीतर सटीक
• टीम सवाल उठाना शुरू कर सकती है कि क्या औपचारिक अनुमान पर्याप्त मूल्य जोड़ता है
• संदर्भ stories की शायद ही कभी आवश्यकता - स्केल आत्मसात हो चुका है

ध्यान किस पर दें:

• हल्के विकल्पों पर विचार करें: Planning Poker कार्डों के बिना त्वरित सहमति
• मूल्यांकन करें कि throughput-आधारित पूर्वानुमान (पॉइंट के बजाय story गणना) आपकी टीम के लिए काम करता है या नहीं
• अनुमान समय केवल उच्च-अनिश्चितता या उच्च-जोखिम stories पर केंद्रित करें
• संभाव्य रिलीज़ नियोजन के लिए Monte Carlo अनुकरण का उपयोग करें

अपेक्षित परिणाम: अनुमान एक हल्की, कम-ओवरहेड प्रथा बन जाती है जो विश्वसनीय रूप से नियोजन का समर्थन करती है।

10 सामान्य सापेक्ष अनुमान गलतियां

गलती #1: सापेक्ष अनुमानों को घंटों में बदलना

क्या होता है: प्रबंधन या टीम एक रूपांतरण स्थापित करती है: "1 Story Point = 4 घंटे।" 5-पॉइंट story से 20 घंटे लगने की अपेक्षा की जाती है।

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

समाधान: कभी भी पॉइंट-से-घंटे रूपांतरण परिभाषित या अनुमति न दें। समय-आधारित नियोजन के लिए Velocity का उपयोग करें: "हमारी औसत Velocity 28 पॉइंट प्रति Sprint है। शेष बैकलॉग 84 पॉइंट है। यह लगभग 3 Sprints है।"

गलती #2: संदर्भ Stories के बिना अनुमान लगाना

क्या होता है: प्रत्येक अनुमान सत्र बिना किसी साझा एंकर के शून्य से शुरू होता है। टीम सदस्य अपने निजी मानसिक मॉडल के आधार पर अनुमान लगाते हैं।

यह हानिकारक क्यों है: संदर्भ stories के बिना, अनुमान समय के साथ बहक जाते हैं। जो तीन महीने पहले 5 था वह अब 3 है, जिससे Velocity रुझान अर्थहीन हो जाते हैं। टीम सदस्य भी अधिक विचलित होते हैं क्योंकि वे अलग-अलग व्यक्तिगत बेसलाइन पर एंकर कर रहे हैं।

समाधान: मुख्य स्केल मानों पर 5-7 संदर्भ stories की सूची बनाए रखें। हर अनुमान सत्र के दौरान उन्हें प्रदर्शित करें। सूची की त्रैमासिक समीक्षा और अपडेट करें।

गलती #3: एक व्यक्ति का अनुमानों पर हावी होना

क्या होता है: सीनियर डेवलपर या टेक लीड पहले बोलता है, और बाकी सब अपना अनुमान उसके अनुसार बदल लेते हैं। या Product Owner टीम के अनुमान से पहले एक आकार सुझाता है।

यह हानिकारक क्यों है: यह एंकरिंग पूर्वाग्रह पैदा करता है - पहली बोली गई संख्या गुरुत्वाकर्षण केंद्र बन जाती है। यह जूनियर टीम सदस्यों को भी चुप कर देता है जिनके पास परीक्षण जटिलता या अनिश्चितता पर मूल्यवान दृष्टिकोण हो सकता है।

समाधान: हर अनुमान के लिए एक साथ प्रकटीकरण (Planning Poker) का उपयोग करें। प्रकटीकरण से पहले कोई अपना अनुमान न बोले। Product Owner story प्रस्तुत करे और प्रश्नों का उत्तर दे लेकिन कभी भी आकार न सुझाए।

गलती #4: एक अनुमान पर बहुत अधिक समय बिताना

क्या होता है: टीम 15-20 मिनट तक बहस करती है कि story 5 है या 8, अक्सर चक्कर लगाती रहती है।

यह हानिकारक क्यों है: एक Sprint में आसपास के Fibonacci मानों के बीच सटीकता का अंतर नगण्य है। 15 मिनट की बहस शून्य पूर्वानुमान सटीकता बचाती है। यह उस ऊर्जा को भी खर्च करती है जो जोखिमों और गलतफहमियों को उजागर करने में जानी चाहिए।

समाधान: प्रति आइटम 3-5 मिनट की समय सीमा निर्धारित करें। यदि टीम दो राउंड के बाद सहमत नहीं हो पाती, तो बड़ा अनुमान चुनें और आगे बढ़ें। यदि बहस से पता चलता है कि story अच्छी तरह समझी नहीं गई है, तो अनुमान जारी रखने के बजाय इसे परिष्करण के लिए वापस भेजें।

गलती #5: टीमों के बीच अनुमानों की तुलना करना

क्या होता है: प्रबंधन देखता है कि टीम A प्रति Sprint 40 पॉइंट पूरा करती है और टीम B 25, और निष्कर्ष निकालता है कि टीम B कम प्रदर्शन कर रही है।

यह हानिकारक क्यों है: Story Points टीम-विशिष्ट हैं। टीम A के "5 पॉइंट" और टीम B के "5 पॉइंट" अलग-अलग मात्रा में काम दर्शाते हैं - उन्होंने अलग-अलग संदर्भ stories और अलग-अलग टीम संरचना के विरुद्ध कैलिब्रेट किया। उनकी तुलना करना अलग-अलग परीक्षाओं के अंकों की तुलना करने जैसा है।

समाधान: यदि क्रॉस-टीम तुलना आवश्यक है, तो वस्तुनिष्ठ मापों का उपयोग करें: throughput (प्रति Sprint पूर्ण stories), साइकल टाइम (शुरू से पूर्णता तक के दिन), या डिलीवर किया गया व्यावसायिक मूल्य। कच्ची Story Point Velocity की तुलना कभी न करें।

गलती #6: व्यक्तिगत प्रदर्शन के लिए सापेक्ष अनुमान का उपयोग

क्या होता है: व्यक्तिगत "Velocity" ट्रैक की जाती है: "सारा ने 18 पॉइंट पूरे किए, कार्लोस ने 12।"

यह हानिकारक क्यों है: यह विकृत प्रोत्साहन बनाता है। डेवलपर्स अधिक उत्पादक दिखने के लिए अनुमान बढ़ाते हैं। सहयोग घटता है क्योंकि सहकर्मी की मदद करने से आपका व्यक्तिगत स्कोर नहीं बढ़ता। जोड़ी प्रोग्रामिंग और मेंटरिंग "Velocity ड्रेन" बन जाती है। टीम विश्वास कमज़ोर होता है।

समाधान: सापेक्ष अनुमान केवल टीम-स्तर डेटा उत्पन्न करता है। व्यक्तिगत प्रदर्शन का मूल्यांकन गुणात्मक मापों से किया जाना चाहिए: कोड समीक्षा गुणवत्ता, ज्ञान साझाकरण, मेंटरिंग, और टीम परिणामों में योगदान।

गलती #7: कैलिब्रेशन छोड़ना

क्या होता है: टीम हर Sprint अनुमान लगाती है लेकिन कभी समीक्षा नहीं करती कि उनके अनुमान सटीक थे या नहीं। वे कभी संदर्भ stories अपडेट नहीं करतीं या व्यवस्थित पूर्वाग्रह नहीं पहचानतीं।

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

समाधान: प्रत्येक Sprint Retrospective में अनुमान सटीकता की समीक्षा के लिए 5 मिनट दें। सबसे बड़ा आश्चर्य (सबसे अधिक या कम अनुमानित story) पहचानें, चर्चा करें क्यों, और तदनुसार संदर्भ stories या अनुमान प्रथाओं को अपडेट करें।

गलती #8: हर चीज़ का अनुमान लगाना

क्या होता है: टीम हर प्रकार के कार्य का अनुमान लगाती है: फ़ीचर, बग, तकनीकी ऋण, स्पाइक, दस्तावेज़ीकरण, और बैठकें। हर चीज़ को Story Points मिलते हैं।

यह हानिकारक क्यों है: बग और स्पाइक स्वाभाविक रूप से अप्रत्याशित हैं - उनका "आकार" तब तक अज्ञात है जब तक आप काम शुरू नहीं करते। उनका अनुमान लगाना झूठी सटीकता बनाता है और Velocity डेटा को अव्यवस्थित करता है। यदि बग पॉइंट Velocity में गिने जाते हैं, तो टीमों को अधिक बग बनाने के लिए प्रोत्साहन मिलता है।

समाधान: Stories (परिभाषित स्वीकृति मानदंड वाले फ़ीचर) का अनुमान लगाएं। बग को गिनती से ट्रैक करें, पॉइंट से नहीं। स्पाइक को अनुमान लगाने के बजाय समयबद्ध करें (जैसे, "शोध में 2 दिन बिताएं")। अनुमान-योग्य न होने वाले कार्य के लिए क्षमता बफर रखें।

गलती #9: गलत स्केल का उपयोग

क्या होता है: टीम रैखिक स्केल (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) का उपयोग करती है, जिससे 6 और 7 के बीच अंतर पर बहस होती है।

यह हानिकारक क्यों है: रैखिक स्केल झूठी सटीकता को प्रोत्साहित करते हैं। 6 और 7 के बीच का अंतर अधिकांश stories के लिए सार्थक रूप से पहचानने योग्य नहीं है, लेकिन स्केल का अस्तित्व बहस को आमंत्रित करता है। समय बिना पूर्वानुमान सुधारे सटीकता पर बर्बाद होता है।

समाधान: Fibonacci (1, 2, 3, 5, 8, 13, 21) या समान गैर-रैखिक स्केल का उपयोग करें। बढ़ते अंतराल अनुमानकर्ताओं को सार्थक, पहचानने योग्य भेद करने के लिए मजबूर करते हैं जबकि बड़े आकारों पर अर्थहीन सटीकता को रोकते हैं।

गलती #10: सापेक्ष अनुमान को बहुत जल्दी छोड़ना

क्या होता है: 3-4 Sprints के शोर वाले Velocity डेटा के बाद, टीम या प्रबंधन घोषित करता है "Story Points काम नहीं करते" और घंटों पर वापस चला जाता है।

यह हानिकारक क्यों है: सापेक्ष अनुमान को विश्वसनीय Velocity डेटा देने के लिए 4-6 Sprints का कैलिब्रेशन चाहिए। 3 Sprints के बाद आंकना डाइट को 3 दिन बाद आंकने जैसा है। शुरुआती शोर कैलिब्रेशन प्रक्रिया का काम कर रहा है - टीम लगातार अनुमान लगाना सीख रही है।

समाधान: मूल्यांकन करने से पहले कम से कम 8 Sprints प्रतिबद्ध रहें कि सापेक्ष अनुमान आपकी टीम के लिए काम करता है या नहीं। समय के साथ Velocity विचरण ट्रैक करें - इसे घटना चाहिए। यदि 8 Sprints के बाद नहीं घटता, तो अनुमान दृष्टिकोण को दोष देने के बजाय मूल कारणों की जांच करें (टीम अस्थिरता, कार्यक्षेत्र परिवर्तन, खराब परिष्करण)।

कई टीमों में सापेक्ष अनुमान को स्केल करना

जब कई टीमें एक ही उत्पाद पर काम करती हैं, तो सापेक्ष अनुमान को समन्वय की आवश्यकता होती है:

साझा संदर्भ stories: यदि टीमों को अनुमानों की तुलना या एकत्रित करने की आवश्यकता है (जैसे, PI नियोजन के लिए), तो 3-5 साझा संदर्भ stories स्थापित करें जिनके विरुद्ध सभी टीमें कैलिब्रेट करें। इससे "सामान्यीकृत" Story Points बनते हैं जो टीमों के बीच मोटे तौर पर तुलनीय होते हैं।

स्वतंत्र Velocity: साझा संदर्भ stories के बावजूद, प्रत्येक टीम अपनी Velocity बनाए रखती है। एक 5-पॉइंट story टीम A को एक दिन और टीम B को तीन दिन ले सकती है - यह ठीक है क्योंकि प्रत्येक टीम की Velocity उनकी विशिष्ट गति को दर्शाती है।

पोर्टफ़ोलियो-स्तर अनुमान: रोडमैप और पोर्टफ़ोलियो नियोजन के लिए, Story Points के बजाय T-shirt sizing या Affinity estimation का उपयोग करें। ये तकनीकें तेज़ हैं और क्रॉस-टीम पॉइंट सामान्यीकरण की आवश्यकता नहीं है।

फ़ीचर-स्तर एकत्रीकरण: जब कोई फ़ीचर कई टीमों में फैलता है, तो प्रत्येक टीम अपने हिस्से का स्वतंत्र रूप से अपने स्केल से अनुमान लगाती है। कुल अनुमान टीम-स्तर अनुमानों का योग है, जो प्रत्येक टीम की Velocity का उपयोग करके Sprints में बदला जाता है। टीमों के बीच कच्चे पॉइंट न जोड़ें - अनुमानित Sprint गणना जोड़ें।

समन्वय समारोह: PI नियोजन या बड़े-कक्ष नियोजन के दौरान, सापेक्ष फ़ीचर आकारों का साझा दृष्टिकोण बनाने के लिए Affinity estimation का उपयोग करें। फिर प्रत्येक टीम Sprint-स्तर नियोजन के दौरान अपने हिस्से को stories में तोड़ती है और अपने Story Point स्केल से अनुमान लगाती है।

निष्कर्ष

सापेक्ष अनुमान काम करता है क्योंकि यह मानव संज्ञान के वास्तविक कार्यप्रणाली के अनुरूप है। हम तुलना करने के लिए बने हैं, भविष्यवाणी करने के लिए नहीं। हम अनुपातिक अंतर अनुभव करते हैं, पूर्ण अंतर नहीं। जब हमारे पास ठोस संदर्भ बिंदु होते हैं तो हम तेज़ और अधिक सटीक निर्णय लेते हैं।

मुख्य निष्कर्ष:

1. सापेक्ष अनुमान कार्य का आकार तुलना से निर्धारित करता है ("क्या यह X से बड़ा है या छोटा?") न कि भविष्यवाणी से ("इसमें कितने घंटे लगेंगे?")
2. Weber-Fechner Law बताता है कि Fibonacci स्केल क्यों काम करता है - हमारा मस्तिष्क अनुपातिक अंतर अनुभव करता है, और स्केल के बढ़ते अंतराल इसे दर्शाते हैं
3. संदर्भ stories आधार हैं - इनके बिना, अनुमान बहक जाते हैं और Velocity अर्थहीन हो जाती है
4. Story Points, T-shirt sizing, Affinity estimation, और Planning Poker सभी सापेक्ष अनुमान तकनीकें हैं - अपनी स्थिति के अनुसार चुनें
5. सापेक्ष और पूर्ण अनुमान सह-अस्तित्व में रह सकते हैं: Sprint Planning के लिए Story Points, कार्य विभाजन के लिए घंटे
6. Story Points को कभी घंटों में न बदलें, टीमों के बीच Velocity की तुलना न करें, या व्यक्तिगत प्रदर्शन के लिए सापेक्ष अनुमानों का उपयोग न करें
7. कैलिब्रेशन आवश्यक है - हर Retrospective में अनुमान सटीकता की समीक्षा करें और संदर्भ stories त्रैमासिक अपडेट करें
8. सापेक्ष अनुमान को विश्वसनीय Velocity डेटा देने के लिए 4-6 Sprints के अभ्यास की आवश्यकता है - इसे समय से पहले न छोड़ें

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