स्प्रिंट प्लानिंग के दौरान "बहुत अधिक" डिज़ाइन किए बिना हम वैध समय अनुमान कैसे प्रदान करते हैं?

Question

मेरी टीम स्क्रम के साथ गति करने के लिए उठ रही है, लेकिन हम में से अधिकांश गैर-फुर्तीली या "छद्म-" चुस्त तरीके से परिचित हैं। वह हिस्सा जो हमारे लिए सबसे बड़ी बाधा है, एक कुशल स्प्रिंट प्लानिंग मीटिंग चल रही है, जहाँ हम अपने बैकलॉग आइटम को कार्यों में तोड़ देते हैं, और घंटों का अनुमान लगाते हैं। (मैं VS2010 स्क्रैम टेम्प्लेट से शब्दावली का उपयोग कर रहा हूं; अगर मैं कहीं गलत शब्द का उपयोग करता हूं तो माफी मांगता हूं।)

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

मुझे पूरा यकीन है कि यह उस तरह का डिज़ाइन करने के लिए उपयुक्त जगह नहीं है। हमें स्प्रिंट के दौरान इन डिज़ाइन बैठकों के लिए कार्य शेड्यूल करना चाहिए। हालांकि, हमें यह पता लगाने में कठिनाई हो रही है कि कार्यों के लिए सार्थक अनुमान कैसे और कैसे लगेंगे।

क्या कोई व्यावहारिक आदतें / तकनीक / आदि हैं। यह जानने के लिए कि आपको इसे लागू करने की योजना के बारे में जानने के बिना, एक कॉल करने में कितना समय लगने वाला है? यदि डिजाइन पूरा हो जाने के बाद हमारे समय के अनुमान में काफी बदलाव होने वाला है, तो हम अपने स्प्रिंट बैकलॉग को समय से पहले कैसे ठीक से बजट बना सकते हैं?

संपादित करें:

बस स्पष्ट करने के लिए, क्योंकि कुछ टिप्पणियां / उत्तर बहुत मान्य हैं, लेकिन मुझे लगता है कि गलत प्रश्न को संबोधित करना।

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

समस्या यह है कि, इस डिज़ाइन प्रक्रिया से गुजरे बिना , हमें किसी भी चीज़ के लिए ठोस समय अनुमान प्रदान करना मुश्किल हो रहा है। हम लगातार चीजों को "अच्छी तरह से कह रहे हैं" अगर हम इसे इस तरह से डिजाइन करते हैं तो इसमें 8 घंटे लग सकते हैं लेकिन अगर हम अंत में इस तरह से करते हैं कि इसके बजाय लगभग 32 हो जाएंगे लेकिन यह उतना बुरा नहीं होगा जितना हम इसे लिखने की कोशिश करना शुरू करते हैं ... "।

मैं यह भी मानता हूं कि एक बार काम करने के लिए हमारे पास कुछ ऐतिहासिक वेग होने के बाद यह प्रक्रिया बेहतर हो जाएगी, लेकिन हमारे द्वारा उपयोग की जाने वाली कई प्रौद्योगिकियां और वास्तुशिल्प पैटर्न हमारे लिए नए हैं। लेकिन अगर संभावित-बेतहाशा-गलत अनुमान इस प्रक्रिया को अपनाने का सिर्फ एक स्वाभाविक हिस्सा है तो हमें बस उस स्वीकार करने के लिए खुद को याद रखने की आवश्यकता होगी :)

Comments

"उपयुक्त" से आपका क्या तात्पर्य है?

— रॉबर्ट हार्वे

मेरा मतलब है कि मुझे नहीं लगता है कि टीम को स्प्रिंट प्लानिंग के दौरान किसी फीचर के तकनीकी डिजाइन पर 25-30 मिनट का समय देना चाहिए, लेकिन यह सिर्फ मेरा अनुभव है (कि यह हमारी योजना बैठकों को लंबा बना रहा है।)

— कुटलुमाइक

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

— इयान

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

— रॉबर्ट हार्वे

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

— कुटलुमाइक

Answer 1

1. एक पुनरावर्ती "ग्रूमिंग" बैठक को शेड्यूल करें जहां आपके पास ये डिज़ाइन चर्चाएं हैं। मैं जिस टीम में हूं, उनके पास एक बार प्रति स्प्रिंट, योजना के पहले दिन। इस लक्ष्य के लिए डिज़ाइन को काफी दूर तक ले जाना है ताकि टीम समग्र कहानी के समय के अनुमानों पर सहमत हो सके। आप इस मीटिंग में टास्क ब्रेकडाउन करने पर विचार कर सकते हैं, ताकि प्लानिंग पूरी तरह से यह तय करने की एक कवायद बन जाए कि कितना लेना है। दूसरे शब्दों में, आपको स्प्रिंट में डिज़ाइन करना चाहिए पहले से ही आप वास्तविक काम करना शुरू कर देंगे।

2. कार्यों का अनुमान लगाने के लिए मानव-दिवस के बजाय नियोजन पोकर , अर्थात "प्रयास" की अंक / इकाइयों का उपयोग करने पर विचार करें । साथ ही कहानियों को जितना हो सके तोड़ने का प्रयास करें। कहानी जितनी लंबी / अधिक जटिल होगी, आपके अनुमान के सही होने की संभावना उतनी ही कम होगी।

3. नियोजन में, स्क्रैम मास्टर को किसी भी चर्चा को रोकने के लिए योजना को ट्रैक पर रखना चाहिए जो "समाधान" में बहुत दूर हो जाते हैं। उस बिंदु पर टीम के सदस्यों को अनुमान पर जल्दी से समझौते की आवश्यकता होती है, आमतौर पर ऊपरी सीमा / सबसे खराब स्थिति संख्या। यदि आप योजना से अधिक आसान काम कर रहे हैं, तो यह अधिक आसान है, क्योंकि यह योजना से अधिक समय तक चलने वाले शेड्यूल से निपटने के लिए है, जो कि नियोजित कार्यों से अधिक समय तक चलना है और कहानियां कई क्षेत्रों में घूमती हैं।

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

Comments

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

— कुटुलुमाइक

Answer 2

मुझे लगता है कि मुद्दा यह है कि आप समय का अनुमान लगाने की कोशिश कर रहे हैं। मत करो।

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

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

मैं माइक कोहन की उपयोगकर्ता कहानियों को लागू करने की अत्यधिक सलाह देता हूं ।

Comments

यह समझ में आता है, लेकिन हम VS2010 स्क्रैम टेम्पलेट का पालन करने की कोशिश कर रहे हैं, इस सिद्धांत पर कि बहुत सारे स्मार्ट लोग जो जानते हैं कि वे क्या कर रहे हैं, वे इसके साथ आए हैं। यदि हम घंटों का अनुमान नहीं लगा रहे हैं, तो हम कार्यों पर शेष काम जैसी चीजों को कैसे ट्रैक करते हैं या एक चार्टडाउन चार्ट बनाते हैं?

— कुटलुमाइक

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

— मैथ्यू फ्लिन

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

— मैथ्यू फ्लिन

उसके बाद, हम वास्तव में कुछ गलत कर रहे हैं। मुझे पता है कि स्क्रैम करने के एक से अधिक तरीके हैं, लेकिन यह वह मार्गदर्शन है जिसका हम उपयोग कर रहे हैं, जो किसी कार्य पर शेष कार्य को ट्रैक करने के लिए कहता है: msdn.microsoft.com/en-us/library/ff731574.aspx । क्या यह सही नहीं है?

— कुटलुमाइक

Ahhhhh। समझा। यह इस तरह से गलत नहीं है, लेकिन जाहिर है यह आपके लिए विशेष रूप से उपयोगी नहीं है। स्क्रम गाइड का कहना है "जैसा कि काम किया जाता है या पूरा किया जाता है, अनुमानित शेष कार्य अपडेट किया जाता है," इसलिए एमएस टेम्प्लेट समझ में आता है। जैसा कि मैंने कहा, यह वास्तव में एक उपयोगी मीट्रिक नहीं है - कोई भी कभी भी किसी कार्य के लिए शेष कार्य का अनुमान लगाने का अच्छा काम नहीं करता है, और आप ऐसा करने की कोशिश में समय बर्बाद करते हैं। अपने कार्यों को छोटा और द्विआधारी (0 = किया या 1 = नहीं) करें, और आपको एक उपाय मिल गया है कि क्या किया गया है और क्या बचा है, और आपको इसके बारे में सोचने की ज़रूरत नहीं है।

— मैथ्यू फ्लिन

Answer 3

मुझे पता है कि आपका प्रश्न विशेष रूप से योजना में डिजाइन से बचने के बारे में है। लेकिन यह एक XY प्रॉब्लम की तरह है ।

मैं वहीं हूं जहां तुम हो आपको ऐसा कुछ देने के बजाय जो एक वृद्धिशील सुधार प्रदान कर सकता है, मैं आपको उन कुछ मध्यवर्ती राज्यों की छलांग लगाने में मदद करना चाहता हूं।

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

स्वचालित स्वीकृति मानदंड

हमारी कहानियों को स्वचालित संख्या मानदंड की उनकी संख्या द्वारा इंगित किया गया है । इसका मतलब है, अगर हमें कहानी की पुष्टि करने के लिए स्वचालित परीक्षण लिखने थे, तो वे क्या होंगे?

उदाहरण के लिए, "जब उपयोगकर्ता iOS 6+ पर चलने वाले iPad पर 'प्ले' पर क्लिक करता है, तो वीडियो चलना शुरू हो जाता है।" इस परीक्षण को वास्तव में स्वचालित करना कठिन हो सकता है, लेकिन यह कहानी का एक स्वीकृति मानदंड (एसी) है और एक बिंदु का योगदान देता है।

हम फाइबोनैचि पैमाने का उपयोग करते हैं, और हम हमेशा गोल होते हैं। इसलिए यदि किसी कहानी में चार स्वचालित स्वीकार्यता मानदंड हैं, तो यह पांच बिंदु वाली कहानी है।

हमारी अधिकतम कहानी बिंदु का आकार आठ अंक है, लेकिन हमारे पास शायद ही है। यदि किसी कहानी में पाँच से अधिक स्वचालित स्वीकार्य मानदंड हैं, तो हम उन्हें विभाजित करने का एक तरीका खोजते हैं।

पूर्व ग्रूमिंग

हमारी सोमवार को एक किकऑफ बैठक है, लेकिन हमारी बैठकें वहीं होती हैं जहां टीम की योजना होती है। ग्रूमिंग से पहले, टीम के सदस्य परिणाम का वर्णन करके और ऑटोमैटिक स्वीकृति मानदंड में एक स्टैब लेकर कहानी तैयार करेंगे ।

ग्रूमिंग टीम की विशेषज्ञता को पहले से तैयार की गई कहानियों को सहन करने, अनिर्दिष्ट आवश्यकताओं को पूरा करने, कहानियों को तोड़ने आदि के लिए लाता है।

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

काम की प्रगति को सीमित करना

पारंपरिक स्क्रम स्प्रिंट की अवधि में काम के समय को सीमित करने का प्रयास करता है । हमने पाया कि यह कृत्रिम रूप से हमें स्प्रिंट की समय सीमा को पूरा करने के लिए प्रेरित करता है, हमारे सप्ताहांत को मारता है क्योंकि स्प्रिंट शुक्रवार को समाप्त होता है।

एक और तरीका यह है कि किसी भी समय कार्य को प्रगति में सीमित किया जाए । हम बाद के लिए चले गए हैं और इसके लिए काफी खुश हैं।

एक बार जब एक कहानी बैकलॉग से काम की ओर बढ़ती है, तो हम इसे कई राज्यों में से एक के रूप में चिह्नित करते हैं:

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

फिर हम टीम का ध्यान केंद्रित करने के लिए प्रत्येक राज्य में कहानियों की संख्या का उपयोग करते हैं। उदाहरण के लिए, एक डेवलपर एक नई कहानी लेने के लिए उपलब्ध हो सकता है, लेकिन अगर हमें बहुत सी कहानियां मिली हैं तो टेस्ट में, उनके लिए मौजूदा कहानियों पर मदद करना बेहतर है।

Answer 4

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

यह यथासंभव छोटी कहानियों को तोड़ने में मददगार है। हमारे पास अक्सर एक शोध / डिजाइन कहानी होती है, जिसमें पर्याप्त काम करने का एकमात्र उद्देश्य यह है कि फीचर को कैसे करना है, इसके बारे में बेहतर विचार है, तो फीचर कहानी बाद में स्प्रिंट में चली जाती है। इस बारे में सोचें कि यह क्यों काम करता है। यहां तक ​​कि अगर आपको पता नहीं है कि कुछ कठिन कैसे होगा, तो आप आमतौर पर पिछले अनुभव से काफी सटीक रूप से जानते हैं कि यह पता लगाने में कितना समय लगेगा।

Answer 5

यहां आप दो चीजें कर सकते हैं।

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

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

फिर से, स्कैम मास्टर को यहां किक करना चाहिए और आपको आइटम को वापस रखने के लिए कहना चाहिए जब तक कि आप इसे शेड्यूल करने के लिए पर्याप्त नहीं जानते हैं, या आपको डिजाइन बंद करने और मूल प्रश्न का उत्तर देने में कितना समय लगेगा (कितना समय लगेगा)।

इसलिए यदि आप स्प्रिंट प्लानिंग कर रहे हैं, तो यह समझ में आता है कि आपके साथ बैकलॉग पर जाने के लिए एक बिजनेस स्पॉन्सर होना चाहिए और जो सामान वे पहले देखना चाहते हैं उसे प्राथमिकता दें। यदि आप ऐसा करते हैं, तो आप पाएंगे कि सत्र के दौरान इसे डिजाइन करना कठिन है क्योंकि वे बेचैन हो जाएंगे और अंततः आना नहीं चाहेंगे।

Comments

हम वास्तव में एक स्कैम मास्टर जोड़ रहे हैं (किसी को स्क्रैम अनुभव के साथ, हमारे लिए इस भूमिका को भरने के लिए काम पर रखा गया है) तो उम्मीद है कि मदद मिलेगी; लेकिन हम सभी मानते हैं कि यह एक समस्या है, मैं इससे जूझ रहा हूं कि इसे बेहतर कैसे किया जाए ।

— कुटलुमाइक

ठीक है, आपने समस्या की पहचान कर ली है। आप बैठक में डिजाइन करते हैं। अगली बैठक आपके पास है, यदि आप खुद को डिजाइन करते हुए पाते हैं, तो रोकें, "हम पर्याप्त नहीं जानते" या "हम पर्याप्त जानते हैं"। यदि आप पर्याप्त नहीं जानते हैं, तो इसे तब तक दबाए रखें जब तक आपके पास अधिक जानकारी न हो (योजना बैठक के बाहर का डिज़ाइन सत्र) यदि आपके पास पर्याप्त जानकारी है, तो इसे शेड्यूल (या नहीं) करें और आगे बढ़ें।

— इयान

एक अन्य टिप्पणी मुझे जोड़ना चाहिए। जब आप एक स्क्रैम मास्टर को रखते हैं तो सावधान रहें। सभी चुस्त तरीकों के साथ, कुंजी को लचीला होना है। जो काम करता है उसे अपनाएं, जो नहीं बदले उसे बदल दें। यह उन कंपनियों के लिए एक बहुत बड़ा बदलाव है, जो प्रक्रियाओं को प्रलेखित और नियोजित योजनाओं को पसंद करते हैं।

— इयान

Answer 6

हम केवल कुछ सीमित चर्चा के साथ स्प्रिंट योजना के दौरान कहानी 'ठंड' का अनुमान लगाने के आधार पर काम कर रहे हैं। अनुमान वास्तव में काफी अचूक फोकस के साथ टीमों की स्थापना के बावजूद काफी गलत हैं ... मुख्य रूप से वास्तव में क्या होने वाला है और क्या होने वाला है, इसके बारे में कोई भी वास्तविक विचार न होने के साथ बहुत सी अनिर्धारित, अनियोजित विरासत कोड के अस्तित्व के कारण। मूल रूप से लिखे जाने के बाद से कर्मचारी जो काफी हद तक बदल चुके हैं।

अब हम जो कोशिश कर रहे हैं, वह प्रत्येक कहानी की जांच करने से पहले कुछ समय बिताने के लिए है - और यहां केवल एक देव एक कहानी की जांच करेगा ... हमें उम्मीद है कि इसका मतलब यह होगा कि जांच करने वाले देव कुछ स्पष्टीकरण और अंतर्दृष्टि प्रदान करने में सक्षम होंगे अनुमान लगाने में मदद करें। अब तक इसने उन अवसरों पर मदद की है, जिन्हें आजमाया गया है।

मुझे अभी तक आश्वस्त नहीं होना है कि अतिरिक्त जांच वास्तव में अनुमानों को लागत का औचित्य साबित करने के लिए पर्याप्त सटीक बनाती है लेकिन हम इसे कुछ क्षेत्रों के लिए देखने की कोशिश करेंगे।