मैं स्प्रिंट प्लानिंग के लिए कहानी के बिंदुओं का उपयोग क्यों नहीं करता

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

जैसा कि एजाइल एस्टिमेटिंग और प्लानिंग में वर्णित है, मैं प्रोडक्ट बैकलॉग के मूल्यांकन के लिए कहानी बिंदुओं का बहुत बड़ा प्रशंसक हूं। हालाँकि, मैं कहानी बिंदुओं के बजाय घंटों में स्प्रिंट बैकलॉग का मूल्यांकन करने की सलाह देता हूं। यह स्पष्ट विरोधाभास क्यों है? पहले मैंने कारणों के बारे में लिखा था। मैं विभिन्न बैकलॉग के लिए माप की विभिन्न इकाइयों (अंक और घंटे) का उपयोग करने की सलाह देता हूं।

लेकिन मुझे अक्सर एक संबंधित प्रश्न पूछा जाता है, जिसे मैं यहां पूछना चाहता हूं:

मैं उत्सुक हूं कि आप स्प्रिंट प्लानिंग के लिए कहानी के बिंदुओं का उपयोग क्यों नहीं कर रहे हैं। मुझे लगा कि कहानी के बिंदुओं में गति मापने की बात यह है कि, यह निर्धारित करने के लिए कि हम स्प्रिंट में कितना (या तय) कर सकते हैं। क्या आप केवल लंबी अवधि की योजना (जैसे रिलीज योजना) के लिए कहानी बिंदुओं का उपयोग करते हैं?

मैं स्प्रिंट प्लानिंग के लिए कहानी के बिंदुओं का उपयोग नहीं करता हूं क्योंकि कहानी बिंदु एक उपयोगी दीर्घकालिक उपाय है। लेकिन अल्पावधि में अंक उपयोगी नहीं होते हैं।

टीम के लिए यह कहना उचित होगा: "हमारे पास औसतन 20 स्टोरी पॉइंट हैं, और हमारे पास 6 स्प्रिंट बचे हैं, इसलिए हम इन छह स्प्रिंट में लगभग 120 स्टोरी पॉइंट खत्म करेंगे।"
टीम के लिए यह कहना अनुचित होगा: "हमारे पास 20 कहानी अंकों की औसत गति है, इसलिए हम अगले स्प्रिंट में समाप्त करेंगे।" यह काम नहीं करता है।

मान लीजिए कि बास्केटबॉल टीम अपने सीजन के बीच में है। आज तक, उन्होंने 41 गेम खेले हैं और प्रति गेम औसतन 98 अंक बनाए हैं। यह कहना उचित होगा: "संभवतः, हम शेष सीज़न में प्रति गेम औसतन 98 अंक प्राप्त करेंगे।" लेकिन उन्हें किसी विशिष्ट खेल से पहले नहीं कहना चाहिए: "हमारे पास औसत 98 है, इसलिए हम आज 98 लेंगे।" इसलिए मैं कहता हूं कि गति एक उपयोगी दीर्घकालिक भविष्यवक्ता है, लेकिन एक उपयोगी अल्पकालिक भविष्यवक्ता नहीं है।

स्प्रिंट से स्प्रिंट तक गति भिन्न होगी।

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

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

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

लेखक के बारे में: माइक Cohn स्करम सॉफ्टवेयर विकास पद्धति के लेखकों में से एक है। वह एजाइल अलायंस और स्क्रैम अलायंस के संस्थापकों में से एक है। वह कंपनियों को उच्च प्रदर्शन वाली टीम बनाने के लिए चुस्त प्रक्रियाओं और विधियों के उपयोग और कार्यान्वयन में मदद करने में माहिर हैं।

सन्दर्भ: एजाइल एस्टिमेटिंग एंड प्लानिंग , माइक कोहन, 2005।

पुनश्च आप घंटे या कहानी अंक में स्प्रिंट बैकलॉग को रेट करते हैं?