स्क्रम स्प्रिंट में परीक्षण कैसे फिट करें और स्क्रम में उपयोगकर्ता कहानियां कैसे लिखें

Question

मैं अपनी कंपनी में एक नए प्रोजेक्ट की विकास टीम लीड हूं। यह पहला प्रोजेक्ट है जहां कंपनी स्क्रैम का उपयोग करेगी। हमारे पास एक झरना / पुनरावृत्त SDLC है। बीए आवश्यकताओं, डॉक्स को सौंपते हैं, देव और परीक्षण को सौंपते हैं, देव विकास करना शुरू करते हैं और पुनरावृत्तियों में परीक्षण के लिए जारी करेंगे। परीक्षकों को एक रिलीज का परीक्षण करने के लिए लंबा समय लगता है जिसके द्वारा devs विकास जारी रखते हैं लेकिन वर्तमान रिलीज़ के लिए बग फिक्स भी करते हैं। मेरे कुछ प्रश्न हैं

1. जब आप परीक्षण के लिए जारी करते हैं, तो 5 कहानियों के साथ एक स्प्रिंट में क्या यह जल्द से जल्द एक कहानी देव द्वारा या सभी कहानियों के पूरा होने के बाद होता है लेकिन स्प्रिंट के अंत से पहले परीक्षण के लिए आवश्यक समय देता है।
2. यदि बीए उपयोगकर्ता कहानियां लिखता है तो विस्तार क्या होना चाहिए। परंपरागत रूप से सभी UI लेआउट, व्यवहार, पाठ आदि के साथ एक युक्ति लिखने के लिए अंतिम रूप देने में लंबा समय लगता है। मुझे लगता है कि मेरा सवाल यह है कि कहानियों को कैसे लागू किया जाए जो लागू करने योग्य और परीक्षण योग्य हो।
3. हमारी परीक्षण टीम गैर-तकनीकी है। स्क्रम के लिए स्वचालित UI परीक्षण होना कितना महत्वपूर्ण है। UI WPF पर आधारित है।

मुझे फुर्तीली विधियों (TDD, कोड रिव्यू, रीफैक्टरिंग आदि) का उपयोग करके ठोस विकास का अनुभव है, लेकिन नए तरीके से।

संपादित करें: पुनरावृत्तियों से मेरा तात्पर्य यह है कि अगर हम १० आवश्यकताओं को पूरा करने के बजाय १०, ३५, ३५, ३५, ३५ आवश्यकताओं को पूरा कर लें, तो हम १०० आवश्यकताओं को पूरा कर सकते हैं।

Comments

We have a waterfall/iterative SDLC.इस पर विस्तार से। झरना, परिभाषा के अनुसार, एक अनुक्रमिक प्रक्रिया है, एक पुनरावृत्त नहीं है। यद्यपि संशोधित झरने हैं (जैसे कि साशिमी मॉडल या झरना-उप-परियोजनाओं के साथ), वे सभी अनुक्रमिक हैं। क्या आप अपनी वर्तमान अनुक्रमिक प्रक्रिया से पुनरावृत्त प्रक्रियाओं की ओर बढ़ने की कोशिश कर रहे हैं?

— थॉमस ओवेन्स

@Pratik चीजें आपके लिए कैसे काम करती हैं? क्या आपने QA टीम के साथ बेहतर सहयोग करने का प्रबंधन किया?

— 21

Answer 1

यदि परीक्षण विकास से अलग है, तो आपके पास दो - अलग - अलग स्कैम टीमें हैं। एक हाथ से दूसरे काम को करना एक बुरा विचार है।

आपके डेवलपर्स को इस अन्य टीम से अलग, अपना परीक्षण लिखना होगा । आपको इस "परीक्षण" टीम को अपने ग्राहकों के रूप में मानना ​​चाहिए।

स्प्रिंट में ... आप परीक्षण के लिए कब जारी करते हैं?

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

मुझे लगता है कि मेरा सवाल यह है कि कहानियों को कैसे लागू किया जाए जो लागू करने योग्य और परीक्षण योग्य हो।

यह टीम से टीम में भिन्न होता है। बीए विकास टीम का हिस्सा है। आपको सही मात्रा में विवरण प्राप्त करने के लिए एक टीम (बीए प्लस डेवलपर्स) के रूप में काम करना होगा। यह टीम का प्रयास है कि बीए से बाकी टीम को सही जानकारी मिले।

स्क्रम के लिए स्वचालित UI परीक्षण होना कितना महत्वपूर्ण है।

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

---

जमीनी स्तर। एक अलग "टेस्ट" टीम और एक बीए जो हर छोटे से विस्तार से लिखता है वह स्क्रम के लिए एक इष्टतम संगठन नहीं है। स्क्रम का मतलब है कि आपको अपने संगठन के साथ-साथ अपनी प्रक्रियाओं पर भी पुनर्विचार करना होगा।

Comments

After you're development team is done, you release it to other teams for "testing" or "deployment" or whatever else happens in the organization. यह Iterative Waterfall से कैसे अलग है? इस मामले में स्प्रिंट सिर्फ एक बहुत छोटा झरना है। इस तरह की एक सबसे बड़ी ताकत एग्री और स्क्रैम आईएमओ को हरा देती है, कि सभी बीए, डेवलपर्स, और क्यूए एक ही टीम में एक साथ हैं और वे सभी सामूहिक रूप से स्प्रिंट के मालिक हैं जो वे जारी कर रहे हैं। यह परियोजनाओं में आने वाली बाधाओं को तोड़ता है।

— maple_shaft

क्या आप विस्तृत कर सकते हैं कि स्वचालित UI परीक्षण क्यों आवश्यक है? स्क्रम एक परियोजना प्रबंधन ढांचा है जो किसी भी तकनीकी अभ्यास को निर्देशित नहीं करता है। परीक्षण के लिए केवल संदर्भ जो मैं स्क्रैम के संबंध में पा सकता हूं कि स्क्रैम टीम एक क्रॉस-फंक्शनल टीम है। हालाँकि मैं स्वचालित परीक्षण को प्राथमिकता दूंगा, लेकिन स्क्रैम को किसी भी स्वचालित परीक्षण की आवश्यकता नहीं होती है और न ही किसी भी परीक्षण की आवश्यकता होती है, हालाँकि पासिंग टेस्ट डेफ़िन की परिभाषा का हिस्सा होना चाहिए। यह सिर्फ यह कहता है कि जो भी परीक्षण किया जाता है वह टीम द्वारा किया जाता है। आपकी निचला रेखा सही है - वर्तमान संगठनात्मक संरचना स्क्रेम के अनुकूल नहीं है।

— थॉमस ओवेन्स

सवाल यह है कि मूल पोस्ट से सही नकल की गई है, जोर दिया गया है: " स्क्रेम के लिए स्वचालित यूआई परीक्षण होना कितना महत्वपूर्ण है ।" स्क्रम के लिए, यह महत्वपूर्ण नहीं है।

— थॉमस ओवेन्स

आपके उत्तर में शब्दांकन ऐसा लगता है जैसे स्वचालित UI परीक्षण स्करम प्रक्रिया का हिस्सा है, और यह नहीं है। लेकिन इसका मतलब यह नहीं है कि गुणवत्ता में सुधार के लिए विकास टीम द्वारा किया जाना अच्छी बात नहीं है। मैं मानता हूं कि यह एक खराब शब्द है, लेकिन "स्क्रैम के लिए यह आवश्यक है" और "एक कहानी के लिए की गई मेरी परिभाषा का हिस्सा होना चाहिए। अंततः, उत्तर नहीं बदलता है, लेकिन यह स्पष्ट हो जाता है कि इसकी आवश्यकता क्यों है।

— थॉमस ओवेन्स

Essential. Completely required.यह प्रतिबिंबित करने के लिए बदलने की जरूरत है कि यह "आवश्यक" या "पूरी तरह से आवश्यक" नहीं है, जो कि स्क्रैम प्रक्रिया ढांचे द्वारा किया गया है। अभी, एक असंबद्ध पाठक इस उत्तर को पढ़ेगा और निष्कर्ष निकालेगा कि यदि आप स्वचालित UI परीक्षण नहीं कर रहे हैं, तो आप स्क्रैम का प्रदर्शन नहीं कर रहे हैं। यह एक गलत निष्कर्ष है, लेकिन इस जवाब के शब्दों को देखते हुए पूरी तरह से समझा जा सकता है। "आपको कुछ करना चाहिए" और "कुछ अनिवार्य है" के बीच एक स्पष्ट अंतर है।

— थॉमस ओवेन्स

Answer 2

अधिकांश उत्तर मैं सॉफ्टवेयर विकास के एक चुस्त तरीके बनाम एक Iterative झरना विधि से संबंधित देने जा रहा हूं। स्क्रम सिर्फ एक लोकप्रिय चुस्त कार्यान्वयन होने के लिए होता है।

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

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

3. स्वचालित UI परीक्षण एक अच्छी बात हो सकती है, लेकिन मुझे व्यक्तिगत रूप से लगता है कि TDD के तरीकों पर अधिक प्रयास और सभी बिजनेस लॉजिक की 100% यूनिट टेस्ट कवरेज अधिक महत्वपूर्ण है। अधिकांश सॉफ़्टवेयर डेवलपमेंट टीम बिजनेस लॉजिक के 100% कवरेज को प्राप्त नहीं कर सकती हैं, इसलिए मेरी राय में स्वचालित यूआई परीक्षण मूल्यवान समय की बर्बादी होगी जिसका उपयोग बीएल के लिए अधिक यूनिट परीक्षण लिखने के लिए किया जा सकता है। यह मेरी राय में एक लक्जरी नहीं एक जरूरत है।

Comments

1 के संबंध में एक वास्तविक प्रश्न: यदि QA प्रत्येक उपयोगकर्ता स्टोरी का परीक्षण जैसे ही किया जाता है, तो अगले एक पर चला जाता है, आप कैसे जांचते हैं कि उसी स्प्रिंट के भीतर की कोई बाद की कहानी टूटी नहीं है (शायद सूक्ष्म तरीके से) उपयोगकर्ता कहानियां जो पहले ही परीक्षण की जा चुकी थीं? एक प्रकार का "एक ही स्प्रिंट के भीतर प्रतिगमन"। मैं मैनुअल क्यूए के बारे में बात कर रहा हूं, स्वचालित परीक्षण सूट नहीं, बिल्कुल।

— एंड्रेस एफ।

@AndresF। यदि सीआई के साथ टीडीडी प्रक्रिया का पालन किया जाता है, तो यदि मौजूदा कार्यक्षमता को तोड़ता है तो यूनिट परीक्षण विफल हो जाएंगे और लोगों को सूचित किया जाएगा। बेशक यह केवल तभी प्रभावी है जब व्यापार तर्क का 100% परीक्षण कवरेज जगह पर है, हालांकि सरल तर्क, पर्यावरण या एकीकरण के मुद्दे, और प्रस्तुति तर्क अभी भी संभावित रूप से नए उपयोगकर्ता कहानी विकास में पेश किए गए दोष हो सकते हैं जो बिना पढ़े चलते हैं। S.Lott द्वारा सुझाया गया स्वचालित UI परीक्षण इनमें से अधिकांश को पकड़ने के लिए एक लंबा रास्ता तय करता है, लेकिन अंततः, एक त्वरित धूम्रपान परीक्षण की तुलना में थोड़ा अधिक इन मुद्दों को देखना चाहिए। जारी है ...

— maple_shaft

... शेष भाग। यदि आप पाते हैं कि यह एक आवर्ती समस्या है, तो आपके पास एक गहरी डिजाइन की खामियां या मुद्दे हो सकते हैं जिन्हें संबोधित करना चाहिए जैसे कि तंग युग्मन और कम सामंजस्य जो आपके कोड को विशेष रूप से भंगुर बनाते हैं।

— maple_shaft

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

— सॉफ्टवेय

@Pratik मैं समझता हूं कि यह मेरे लिए कितना मुश्किल है। मुझे दर्द का पता है। शायद आप स्प्रिंट का विस्तार कर सकते हैं लेकिन प्रति स्प्रिंट परीक्षण पर्यावरण के लिए तीन या चार रिलीज हैं? इस तरह परीक्षण टीम परीक्षण के मामले के बीच में दिन के लिए रवाना हो सकती है और आश्वस्त हो सकती है कि वातावरण रातोंरात नहीं बदला गया है।

— maple_shaft

Answer 3

1. स्क्रम में, आपको प्रत्येक स्प्रिंट के अंत में एक संभावित shippable सॉफ़्टवेयर वेतन वृद्धि का उत्पादन करना चाहिए । नतीजतन, स्क्रम पूरी टीम या क्रॉस-फंक्शनल टीम की अवधारणा को बढ़ावा देता है, जहां दिए गए उपयोगकर्ता कहानी का नेतृत्व करने के लिए आवश्यक प्रत्येक कौशल को टीम में उपस्थित होना पड़ता है।

   मेरी वर्तमान परियोजना में, चूंकि पूरी तरह से परीक्षण की गई कहानी हमारी पूरी की गई परिभाषा का हिस्सा है, हमारे पास टीमों में परीक्षक हैं। स्प्रिंट के पहले कुछ दिनों के दौरान, जबकि डेवलपर्स पहले उपयोगकर्ता कहानियों पर काम करना शुरू करते हैं, परीक्षक परीक्षण परिदृश्य तैयार करेंगे और परीक्षण डेटा सेट करेंगे। जैसे ही उपयोगकर्ता कहानियों में से एक के लिए देव समाप्त हो जाते हैं, वे इसका परीक्षण करेंगे।

2. यह स्क्रम आईएमओ में सबसे बड़ी कठिनाइयों में से एक है। आपको एक कार्यान्वयन योग्य, परीक्षण योग्य उपयोगकर्ता कहानी प्राप्त करने के लिए आवश्यक विनिर्देश की सही मात्रा का पता लगाना होगा। बहुत अधिक विश्लेषण, प्रलेखन और विनिर्देश एक कठोर योजना के परिणामस्वरूप होंगे जो अनिवार्य रूप से स्प्रिंट के दौरान गलत साबित होंगे। इसके विपरीत, एक उपयोगकर्ता कहानी जिसे उत्पाद स्वामी द्वारा स्पष्ट रूप से परिभाषित और व्यक्त नहीं किया गया है, विकास के दौरान स्प्रिंट के दौरान डेवलपर्स और पीओ के बीच एक संतृप्त संचार बैंडविड्थ को बढ़ावा देगा और विकास में देरी होने पर पीओ उपयोगकर्ता को स्प्रिंट के माध्यम से आधे रास्ते के बारे में निर्णय लेता है। ।

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

3. मेरे अनुभव में, स्वचालित यूआई परीक्षण अत्यंत समय लेने वाली और बेहद भंगुर है। डब्ल्यूपीएफ में ऐसा करने के तरीके हैं, लेकिन मैं इस तरह से जाने से पहले इस तरह के परीक्षणों की लागत को ध्यान से बताऊंगा।

Answer 4

छोटे और छोटे पुनरावृत्तियों में काम करना इन सभी हैंडऑफ़ को अधिक से अधिक महंगा बनाता है। आप एक मूर्खतापूर्ण, सरल नियम का पालन करके इन लागतों को कम कर सकते हैं: आधे में बैच के आकार में कटौती, आप कैसे उस आरामदायक बनाने के लिए काम करते हैं, खुश होने तक दोहराएं।

अपनी 5-कहानी स्प्रिंट उदाहरण लें। यदि आपकी टीमें सभी 5 कहानियों के लिए कोड लिखने की आदी हैं, तो सभी 5 कहानियों का परीक्षण करें, फिर बैच का आकार 5 कहानियां हैं। उसको आधा में काटें। अगले स्प्रिंट में, 3 सबसे जरूरी कहानियों पर पहले काम करें, उन्हें परीक्षण के लिए तैयार करें जितनी जल्दी हो सके। जैसा कि परीक्षक उन 3 कहानियों का परीक्षण कर रहे हैं, शेष 2 कहानियों को परीक्षण के लिए तैयार कर सकते हैं। यह कुछ बढ़ते दर्द का कारण होगा। इसे और अधिक आरामदायक बनाने के लिए आप कैसे काम करते हैं, इसे बदलें।

उदाहरण के लिए, अधिक लोग प्रत्येक कहानी पर एक साथ काम करेंगे, इसलिए अधिक जोड़ी बनाने की कोशिश करें और देखें कि क्या आप अधिक तेजी से काम करने में मदद करते हैं। या, शायद, परीक्षकों को कहानी 2 में समस्याएं मिलेंगी जो कुछ प्रोग्रामर को विचलित करती हैं, जबकि वे कहानी 5 पर काम करने की कोशिश कर रहे हैं, इसलिए प्रोग्रामर और परीक्षक अगले स्प्रिंट को प्रोत्साहित करें कि पहले कहानी में से एक का परीक्षण कैसे करें "पहले बैच में" "ताकि प्रोग्रामर को एक गलती करने की संभावना कम हो कि एक परीक्षक एक परीक्षण के साथ आसानी से पकड़ सकता है।

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

बेशक, इस बिंदु पर, अब आप बैचों के साथ वही काम कर सकते हैं जो टीम उत्पाद मालिकों से प्राप्त करती है, या यह कि टीम संचालन संगठन को जहाज देती है। और इसी तरह। इस बिंदु पर, आप "कहानियों के लिए बीए को कितना विस्तार से लिखना चाहिए?" मुसीबत।

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

मुझे उम्मीद है कि उससे आप मदद मिलती है।

Answer 5

बस नीचे कुछ अनुभव साझा करना चाहते हैं, आशा है कि यह आपके लिए उपयोगी है।

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

प्रत्येक बड़ी उपयोगकर्ता कहानी के लिए, इसे कई उप-कार्यों के लिए तोड़ दिया जाना चाहिए और जब उप-कार्य पूरी तरह से डेवलपर द्वारा किए जाते हैं, तो उन्हें तुरंत परीक्षण के लिए क्यूसी को जारी किया जाना चाहिए। उन उप-कार्य समाप्त परीक्षण के लिए परीक्षण के बाद दोष तय किया जाना चाहिए।

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

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

हमारी परीक्षण टीम गैर-तकनीकी है। स्क्रम के लिए स्वचालित UI परीक्षण होना कितना महत्वपूर्ण है। UI WPF पर आधारित है

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