स्क्रम: बैकलॉग-आइटम को कैसे संभालना है जो एक स्प्रिंट से अधिक लंबा है

Question

मैं SCRUM से शुरुआत कर रहा हूं और मुझे एक बात समझने में समस्या है। SCRUM बैकलॉग आइटम को कैसे संभालता है जो एक से अधिक स्प्रिंट लेते हैं?

Comments

क्या आपने उन्हें सार्थक बैकलॉग आइटम में विभाजित करने की कोशिश की?

— डेविड

फिलहाल, यह अधिक समस्या है कि मुझे लगता है कि मैं भविष्य में सामना करूंगा - और मैं इसे सही तरीके से संभालना चाहता हूं।

— टोबियास लैंगनर

Answer 1

ऐसी वस्तुओं को या तो एपिक कहा जाता है और उन्हें छोटी उपयोगकर्ता कहानियों में विभाजित किया जाना चाहिए जो कि छोटी हैं और फिर एकल स्प्रिंट की वजह से हो सकती हैं और इसकी योजना बनाई जा सकती है, या थीम जिन्हें एपिक्स और उन आम कहानियों में विभाजित किया जाएगा। महाकाव्य और विषय-वस्तु मुख्य विशेषता को साझा करते हैं - उच्च स्तर की अनिश्चितता = वे ठीक से अनुमान नहीं लगा सकते हैं (अनुमान आमतौर पर बहुत अधिक है और इस वजह से वे एक ही स्प्रिंट में फिट नहीं होते हैं)।

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

यह उत्पाद बैकलॉग की आइसबर्ग संरचना का भी अनुसरण करता है।

Answer 2

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

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

Answer 3

जब स्क्रम पहली बार "आविष्कार" किया गया था, तो डिफ़ॉल्ट स्प्रिंट आम तौर पर 4 सप्ताह था।

मुझे जो बताया गया है, उसके अनुसार इस बहुत लंबे स्प्रिंट आकार का कारण सिर्फ इसलिए था क्योंकि उस समय के लोगों के पास यह कल्पना करने में बहुत कठिन समय था कि आप संभवतः छोटे स्प्रिंट में कुछ भी हासिल कर सकते हैं।

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

आज, मेरा मानना ​​है कि अधिकांश टीमें 4 सप्ताह को बहुत लंबी स्प्रिंट अवधि मानेंगी। मुझे आभास है कि 2 सप्ताह काफी सामान्य है। XP टीमें केवल 1 सप्ताह की पुनरावृत्तियां करती हैं, और वे प्रत्येक पुनरावृत्ति में पूर्ण उपयोगकर्ता कहानियां समाप्त करती हैं।

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

Answer 4

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

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

यहाँ एक शानदार पोस्टर है जो कहानियों को विभाजित करने में मदद करता है, इसकी वेबसाइट agileforall.com से है और आप पोस्टर को यहाँ पा सकते हैं, इसका वास्तव में उपयोगी यह है कि आप बैकलॉग आइटम को परिष्कृत करें:

http://agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

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

Comments

वर्तमान प्रस्ताव पर यह पोस्टर लगभग पूरी तरह से अप्राप्य है।

— ब्रायन ओकले

क्षमा याचना, संपादित लिंक का प्रयास करें ;-)

— एंथनी जोएन्स

पैटर्न-फॉर-स्प्लिटिंग-यूजर- स्टोरीज लिंक फ्लोचार्ट का वर्णन करता है और संबंधित स्टोरी-स्प्लिटिंग-चीट-शीट में कम informations है, लेकिन पढ़ने के लिए बहुत आसान है।

— k3b