स्प्रिंट योजना: Agile सर्वश्रेष्ठ अभ्यास

योजना के मूल सिद्धांत

अच्छी स्प्रिंट प्लानिंग के लिए एक व्यवस्थित तरीका चाहिए, जिसमें पिछले स्प्रिंट का विश्लेषण, टीम की क्षमता का आकलन और लक्ष्यों की साफ़ परिभाषा शामिल हो। अधिक जानकारी: आईटी टीमों के लिए आईटी प्रोजेक्ट मैनेजमेंट सॉफ्टवेयर।

1. योजना की तैयारी काफ़ी पहले शुरू हो जानी चाहिए। Product Owner को मीटिंग से कम से कम एक दिन पहले backlog तैयार करके उसकी प्राथमिकताएं तय कर देनी चाहिए, ताकि विकास टीम user story पहले से पढ़ सके और जो बात अस्पष्ट हो उस पर सवाल पूछ सके।
2. समय बांटने का पारंपरिक नियम: स्प्रिंट के हर सप्ताह के लिए दो घंटे की योजना, यानी दो सप्ताह के स्प्रिंट के लिए चार घंटे। हालांकि अनुभव बताता है कि इस समय को एक लंबी बैठक में खर्च करने के बजाय कई छोटे सत्रों में बांटना अक्सर बेहतर काम करता है।

तैयारी चरण

अच्छी तैयारी के बिना स्प्रिंट प्लानिंग को सुधारना संभव नहीं है। इस चरण को अक्सर हल्के में लिया जाता है, जबकि पूरी प्रक्रिया की सफलता इसी पर टिकी होती है।

• Definition of Ready (DoR) वे शर्तें तय करता है जिन्हें पूरा किए बिना कोई user story स्प्रिंट में नहीं ली जाती। हर स्टोरी में साफ़ स्वीकृति मानदंड, जटिलता का अनुमान और दूसरे कार्यों पर पहचानी गई निर्भरताएं होनी चाहिए। DoR का पालन न हो तो योजना बैठक अव्यवस्थित हो जाती है और टीम काम की योजना बनाने के बजाय बातें स्पष्ट करने में समय गंवाती है।
• Backlog refinement नियमित रूप से होना चाहिए, केवल स्प्रिंट प्लानिंग से ठीक पहले नहीं। इसके लिए स्प्रिंट के समय का 10% अलग रखना एक मानक अभ्यास है। टीमें सप्ताह में कई बार छोटे रिफाइनमेंट सत्र रख सकती हैं और आने वाले स्प्रिंट की स्टोरीज पर धीरे-धीरे काम कर सकती हैं।
• Velocity विश्लेषण से टीम को पता चलता है कि वह वास्तव में कितना काम पूरा कर सकती है। इसमें पिछले 3-5 स्प्रिंट की औसत Velocity के साथ उन बातों को भी देखना चाहिए जो अगले स्प्रिंट में उत्पादकता घटा सकती हैं, जैसे तय अवकाश, छुट्टियां, जमा हुआ तकनीकी ऋण या बाहरी निर्भरताएं।

योजना सत्र

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

1. टीम, Product Owner के साथ मिलकर, स्प्रिंट लक्ष्य तय करती है, जो चुनी गई सभी user story को एक सूत्र में जोड़ता है। लक्ष्य विशिष्ट, मापने योग्य और सभी प्रतिभागियों के लिए सार्थक होना चाहिए। कमज़ोर लक्ष्य का उदाहरण है "उपयोगकर्ता अनुभव में सुधार", जबकि अच्छा लक्ष्य है "उपयोगकर्ता एक क्लिक में सोशल मीडिया के माध्यम से पंजीकरण कर सकेंगे।"
2. विकास टीम चुनी गई स्टोरीज को कार्यों में बांटती है और हर कार्य का अनुमान घंटों में लगाती है, जिससे वे छिपी जटिलताएं और निर्भरताएं सामने आ जाती हैं जो स्टोरी के स्तर पर दिखाई नहीं देतीं। कोई भी कार्य 8 घंटे से अधिक का नहीं होना चाहिए, और जो कार्य इस सीमा से बड़ा हो उसे उप-कार्यों में और बांटना चाहिए।

भूमिकाएं और जिम्मेदारियां

स्प्रिंट प्लानिंग तभी अच्छी तरह चलती है जब हर प्रतिभागी अपनी भूमिका समझता है और उसी के भीतर रहकर काम करता है।

• Scrum Master प्रक्रिया का संचालन करता है, टाइमबॉक्स का पालन करवाता है और टीम को निर्णय तक पहुंचने में मदद करता है। वह अपना समाधान नहीं थोपता, सही सवाल पूछता है और चर्चा को भटकने नहीं देता।
• Product Owner backlog की प्राथमिकताओं के लिए और इस निर्णय के लिए जिम्मेदार है कि कौन सी सुविधाएं पहले बनेंगी। उसे हर स्टोरी का व्यावसायिक मूल्य समझाने और विकास टीम के सवालों का इतना सटीक जवाब देने के लिए तैयार रहना चाहिए कि टीम अनुमान लगा सके।
• विकास टीम परिणाम देने की प्रतिबद्धता लेती है। यह प्रतिबद्धता बाहर से सौंपी नहीं जानी चाहिए, टीम को इसे खुद लेना चाहिए, क्योंकि जो वादा टीम स्वयं करती है उसमें प्रेरणा और जवाबदेही का स्तर थोपे गए लक्ष्य से कहीं अलग होता है।

सामान्य गलतियाँ

• अपनी क्षमता को बढ़ा-चढ़ाकर आंकना स्प्रिंट प्लानिंग की सबसे आम गलती है। टीमें बार-बार जितना पूरा कर सकती हैं उससे अधिक काम ले लेती हैं, खासकर परियोजना की शुरुआत में या किसी सफल स्प्रिंट के बाद। यहां काम का सिद्धांत यह है कि कम वादा करके अधिक देना बेहतर है, क्योंकि अधूरे वादे हितधारकों का भरोसा घटाते हैं और अगले स्प्रिंट में टीम का उत्साह भी कम कर देते हैं।
• समय का बफर न रखना एक गंभीर संरचनात्मक गलती है। स्प्रिंट योजना में अप्रत्याशित कार्यों, बग और तकनीकी सहायता के अनुरोधों के लिए 10-20% समय अलग रखना चाहिए। इस रिज़र्व को पहले से अतिरिक्त स्टोरीज से नहीं भरना चाहिए, क्योंकि इसका काम उस अनियोजित काम को संभालना है जो हर स्प्रिंट में आता ही है।
• निर्भरताओं को नज़रअंदाज़ करने से स्प्रिंट के बीच में रुकावटें खड़ी हो जाती हैं। सभी बाहरी निर्भरताओं को योजना के समय ही पहचानकर सुलझा लेना चाहिए। अगर कोई कार्य किसी दूसरी टीम या बाहरी विक्रेता पर निर्भर है, तो स्प्रिंट शुरू होने से पहले ही समय सीमा पर सहमति बनाकर उसकी पुष्टि ले लेनी चाहिए।

प्रक्रिया निगरानी

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

विश्लेषण के लिए मेट्रिक्स:

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

Burndown चार्ट पूरे स्प्रिंट की प्रगति दिखाते हैं और समस्याओं को इतनी जल्दी सामने ले आते हैं कि उन्हें समय रहते ठीक किया जा सके। जब चार्ट से लगे कि टीम योजना का काम पूरा नहीं कर पाएगी, तब सुधार के कदम उठाने चाहिए, जैसे बचे हुए कार्यों की प्राथमिकता फिर से तय करना या सबसे कम प्राथमिकता वाली user story को स्प्रिंट के दायरे से हटा देना।

योजना को अनुकूलित करना

• दूरस्थ टीमों को स्प्रिंट प्लानिंग अपनी परिस्थिति के अनुसार ढालनी पड़ती है। इसके लिए सहयोग के उपयुक्त उपकरण होने चाहिए और यह ध्यान रखना चाहिए कि हर दूरस्थ प्रतिभागी को बराबर भागीदारी का अवसर मिले। ऐसी टीमों में एक लंबी बैठक के बजाय कई छोटे सत्रों में योजना बनाने से लोग अधिक जुड़े रहते हैं और परिणाम भी बेहतर निकलता है।
• कई टीमों वाले बड़े कार्यक्रमों में कार्यक्रम के स्तर पर तालमेल की आवश्यकता होती है। जिन टीमों की निर्भरताएं साझा हैं, उनकी स्प्रिंट प्लानिंग को एक साथ चलाने के लिए Scrum of Scrums या SAFe (Scaled Agile Framework) जैसे ढांचे काम आते हैं।
• रखरखाव परियोजनाओं में स्प्रिंट का बड़ा हिस्सा सहायता और बग सुधारने में जाता है, इसलिए अनियोजित काम के लिए क्षमता पहले से अलग रखनी पड़ती है। आम तौर पर स्प्रिंट की क्षमता का 30-50% सहायता कार्य के लिए रखा जाता है और बाकी नई सुविधाओं के विकास के लिए, जिससे वे विफलताएं नहीं होतीं जो सहायता कार्य को नियोजित क्षमता के बजाय ऊपरी बोझ मानने पर होती हैं।

संबंधित लेख:

परियोजना प्रबंधन ढांचे और बाधा संतुलन के लिए, पढ़ें परियोजना प्रबंधन त्रिकोण: दायरा, समय और लागत संतुलित करना।

Kanban बोर्डों और दृश्य कार्यप्रवाह प्रबंधन के व्यावहारिक अवलोकन के लिए, पढ़ें Kanban बोर्ड क्या है? दृश्य कार्यप्रवाह प्रबंधन के लिए एक गाइड।

Agile टीमें वास्तविक उपयोगकर्ता आवश्यकताओं के साथ संरेखित रहने के लिए व्यक्तित्व का उपयोग कैसे करती हैं, पढ़ें Agile व्यक्तित्व: Agile परियोजनाओं में उपयोगकर्ता-केंद्रित विकास को बढ़ाना। और पढ़ें: कानबन बोर्ड।

निष्कर्ष

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