यूज़र स्टोरी और इटरेशन प्लानिंग

यूज़र स्टोरी किसी उपयोगकर्ता की ज़रूरत का एक छोटा विवरण है, जो उसके दृष्टिकोण से लिखा जाता है। इटरेशन प्लानिंग वह तरीका है जिससे टीम तय करती है कि अगली समय-सीमा में वह किन स्टोरी पर काम करेगी। कई टीमें इस समय-सीमा को स्प्रिंट और बैठक को स्प्रिंट प्लानिंग कहती हैं; East Agile Tracker इन्हें इटरेशन और इटरेशन प्लानिंग कहता है।

यूज़र स्टोरी क्या है

आम टेम्पलेट यह है:

एक [उपयोगकर्ता का प्रकार] के रूप में, मैं [कोई क्षमता] चाहता हूँ, ताकि [कोई लाभ]।

उदाहरण के लिए: एक प्रोजेक्ट मैनेजर के रूप में, मैं देखना चाहता हूँ कि कौन-सी स्टोरी ब्लॉक हैं, ताकि मैं इटरेशन ख़त्म होने से पहले उन्हें सुलझा सकूँ।

यह टेम्पलेट बताता है कि लाभ किसे होता है, उसे क्या चाहिए और क्यों। “क्यों” से टीम वही लाभ देने का कोई सरल तरीका ढूँढ पाती है। स्टोरी एक बातचीत का स्थान-धारक है, पूरा विनिर्देश नहीं: विवरण माँगने वालों और बनाने वालों के बीच तय होते हैं।

INVEST: क्या स्टोरी तैयार है?

INVEST एक अच्छी तरह से गठित स्टोरी की जाँच-सूची है:

• Independent (स्वतंत्र) — अपने आप में बनाई और डिलीवर की जा सकती है।
• Negotiable (बातचीत योग्य) — विवरण चर्चा के लिए खुले हैं।
• Valuable (मूल्यवान) — कुछ ऐसा डिलीवर करती है जिसकी उपयोगकर्ता या ग्राहक को परवाह है।
• Estimable (अनुमान योग्य) — टीम इसे इतनी अच्छी तरह समझती है कि इसका आकार तय कर सके।
• Small (छोटी) — एक इटरेशन में आराम से समा जाती है।
• Testable (परीक्षण योग्य) — यह बताने का एक स्पष्ट तरीका है कि वह पूरी हो गई है।

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

स्वीकृति मानदंड बताते हैं कि स्टोरी को done मानने के लिए क्या सच होना चाहिए। उन्हें Given / When / Then रूप में लिखने से हर मानदंड एक स्वीकृति परीक्षण बन जाता है:

Given एक स्टोरी जिसका कोई ब्लॉकर अनसुलझा है, when मैं Blocked कॉलम खोलता हूँ, then वह स्टोरी वहाँ सूचीबद्ध होती है।

मानदंड काम शुरू होने से पहले तय किए जाते हैं, ताकि टीम और स्टोरी स्वीकार करने वाले व्यक्ति के पास done की एक ही परिभाषा हो।

इटरेशन प्लानिंग

इटरेशन प्लानिंग एक प्रश्न का उत्तर देती है: इस इटरेशन में हम किस पर काम करेंगे? इसके लिए तीन इनपुट चाहिए:

1. एक क्रमबद्ध बैकलॉग — प्राथमिकता के अनुसार क्रमित स्टोरी, जिनमें शीर्ष वाली तैयार हों (INVEST पर खरी, स्वीकृति मानदंडों के साथ)।
2. अनुमान — हर संभावित स्टोरी का आकार स्टोरी पॉइंट में।
3. वेलोसिटी — टीम प्रति इटरेशन कितने पॉइंट पूरे करती है। वेलोसिटी क्या है? देखें।

टीम बैकलॉग के शीर्ष से स्टोरी तब तक लेती है जब तक कुल योग उसकी वेलोसिटी तक न पहुँच जाए। उससे अधिक लेना इस भरोसे पर टिका है कि टीम अचानक तेज़ काम करने लगेगी; कम लेने से क्षमता अप्रयुक्त रह जाती है।

East Agile Tracker इसे कैसे करता है

• स्टोरी चार प्रकार की होती हैं: फ़ीचर, बग, चोर और रिलीज़। डिफ़ॉल्ट रूप से केवल फ़ीचर को पॉइंट मिलते हैं। स्टोरी देखें।
• स्वीकृति मानदंड विवरण में जाते हैं। कोई अलग फ़ील्ड नहीं है; मानदंड स्टोरी शुरू होने से पहले विवरण में होने चाहिए। जब कोई स्टोरी डिलीवर होती है, तो प्रोडक्ट ओनर उन्हीं मानदंडों के विरुद्ध उसे स्वीकार या अस्वीकार करता है। स्टेट मशीन और स्वीकृति लूप देखें।
• बैकलॉग एक सख़्ती से क्रमबद्ध सूची है, और यह वेलोसिटी से तीन या चार आगामी इटरेशनों का प्रक्षेपण करता है, तथा वेलोसिटी से अधिक वाले किसी भी समूह को चिह्नित करता है। इटरेशन देखें।
• इटरेशन प्लानिंग अधिकतर स्वचालित है। auto-plan iterations चालू होने पर (डिफ़ॉल्ट), वर्तमान इटरेशन आपकी वेलोसिटी तक भरता है; कोई नई स्टोरी खींचने पर सबसे कम-प्राथमिकता वाली स्टोरी वापस Backlog के शीर्ष पर चली जाती है। जो टीमें Scrum की तरह एक निश्चित स्कोप के लिए प्रतिबद्ध होती हैं, वे auto-plan बंद करके जितना चाहें उतनी योजना बना सकती हैं, और वेलोसिटी से ऊपर जाने पर एक काउंटर लाल हो जाता है। एक इटरेशन की योजना बनाना देखें।
• स्टोरी बनाने पर शीर्षक, विवरण, प्रकार, अनुमान और ओनर के लिए एक कंपोज़र खुलता है। एक स्टोरी बनाएँ देखें।

आगे पढ़ें

• स्टोरी पॉइंट क्या हैं? — स्टोरी का आकार तय करना।
• वेलोसिटी क्या है? — योजना का क्षमता वाला पक्ष।
• eXtreme Programming — यूज़र स्टोरी और planning game कहाँ से आए।