हमारी स्क्रम टीमों में हम एक बैकलॉग का उपयोग करते हैं, जिसमें अधिकतर कार्यात्मक विषय होते हैं, लेकिन कभी-कभी तकनीकी विषय भी होते हैं। 1 बैकलॉग होने का लाभ यह है कि अगले स्प्रिंट के लिए विषयों को चुनना आसान हो जाता है, लेकिन मेरे पास कुछ प्रश्न हैं:
- सबसे पहले, मेरे लिए एक अलग तकनीकी बैकलॉग होना अधिक तर्कसंगत लगता है, जहां डेवलपर्स स्वयं शुद्ध तकनीकी आइटम जोड़ सकते हैं, जैसे: हम इस पद्धति में प्रदर्शन में सुधार कर सकते हैं, इस वर्ग में कुछ तकनीकी दस्तावेज का अभाव है, ... एक बैकलॉग होने से, सभी डेवलपर्स को हमेशा अपने विषय को बैकलॉग में जोड़ने के लिए उत्पाद स्वामी से गुजरना पड़ता है, जो उत्पाद स्वामी के लिए अतिरिक्त, अनावश्यक काम लगता है।
- दूसरा, यदि आपके पास एक उत्पाद का स्वामी है जो केवल शुद्ध-कार्यात्मक वस्तुओं पर ध्यान केंद्रित करता है, तो शुद्ध-तकनीकी आइटम (जैसे लापता तकनीकी दस्तावेज, कोड जो मिट जाता है और इसे फिर से भरना चाहिए, कक्षाएं जो हमेशा डिबगिंग के दौरान समस्याएं देती हैं क्योंकि उनके पास नहीं है एक स्थिर नींव और फिर से बनाया जाना चाहिए, ...) हमेशा सूची के अंत में समाप्त होता है क्योंकि "वे सीधे ग्राहक की सेवा नहीं करते हैं"। एक अलग तकनीकी बैकलॉग होने से, और इन शुद्ध तकनीकी वस्तुओं के लिए हर स्प्रिंट में आरक्षित समय, हम अनुप्रयोगों को कार्यात्मक रूप से सुधार सकते हैं, लेकिन उन्हें अंदर से स्वस्थ भी रख सकते हैं।
सबसे अच्छा तरीका क्या है? एक बैकलॉग या दो?