موبائل ڈویلپمنٹ میں سپرنٹ: جوہر، مدت اور منصوبہ بندی

ڈویلپمنٹ میں سپرنٹ کیا ہے؟

سپرنٹ مقررہ مدت کا ایک ٹائم باکس ہے جس کے اختتام پر ٹیم استعمال کے لیے تیار مصنوعات کا اضافہ فراہم کرتی ہے۔ سپرنٹ کا تصور Scrum کی بنیاد ہے، لیکن یہ دیگر Agile فریم ورکس میں بھی استعمال ہوتا ہے۔ موبائل ڈویلپمنٹ میں، اضافہ ایپلیکیشن کا ایک بلڈ ہے جسے ڈیوائس پر انسٹال کیا جا سکتا ہے، ٹیسٹ کیا جا سکتا ہے اور اسٹیک ہولڈرز کو دکھایا جا سکتا ہے۔ سپرنٹ کو بڑھایا نہیں جا سکتا — اگر کام مکمل نہیں ہوتے، تو وہ اگلے سپرنٹ میں منتقل ہو جاتے ہیں۔

سپرنٹ کی اہم خصوصیت مقررہ مدت ہے۔ ٹیم منظوری کے بعد سپرنٹ کا مقصد تبدیل نہیں کرتی۔ یہ پیشین گوئی فراہم کرتا ہے: اسٹیک ہولڈرز جانتے ہیں کہ انہیں نتیجہ کب ملے گا۔ سپرنٹ کے اندر، ٹیم فیصلہ کرتی ہے کہ کام کیسے تقسیم کیا جائے۔ Scrum Master ٹیم کو بیرونی مداخلت سے بچاتا ہے — موجودہ سپرنٹ میں نئے کام شامل نہیں کیے جاتے۔ Scrum Guide 2025 کے مطابق، پائیدار ترقی کی رفتار برقرار رکھنے کا یہ واحد طریقہ ہے۔

ایک سپرنٹ چار لازمی واقعات پر مشتمل ہوتا ہے: Sprint Planning، Daily Scrum (یومیہ ہم آہنگی)، Sprint Review (نتیجہ کا مظاہرہ)، Sprint Retrospective (عمل کا تجزیہ)۔ ان کے درمیان اہم کام ہوتا ہے: کاموں کا نفاذ، جانچ، کوڈ کا جائزہ۔ مدت ہر واقعہ کی سپرنٹ کی لمبائی کے براہ راست متناسب ہے: 2 ہفتے کے سپرنٹ کے لیے، Planning 4 گھنٹے، Review 2 گھنٹے، Retro 1.5 گھنٹے، Daily 15 منٹ۔ مجموعی طور پر رسومات میں فی سپرنٹ تقریباً 8 گھنٹے لگتے ہیں — ٹیم کے کام کرنے کے وقت کا 10%۔

سپرنٹ کی Scrum رسومات

Scrum رسومات (تقاریب/واقعات) سپرنٹ کے اندر منظم ٹیم میٹنگیں ہیں۔ Sprint Planning شروع میں، Daily Scrum ہر روز، Sprint Review اور Retrospective آخر میں۔ تمام واقعات کا ایک ٹائم باکس ہوتا ہے۔ Scrum Master ٹائم باکس اور توجہ کی تعمیل کو یقینی بناتا ہے۔ پوری Scrum ٹیم ہر رسم میں شرکت کرتی ہے: Product Owner، Scrum Master، ڈویلپرز۔ استثنا Daily Scrum ہے (صرف ڈویلپرز شرکت کرتے ہیں، PO اور SM اختیاری ہیں)۔

رسومات کا سپرنٹ مراحل سے تعلق: Planning سمت متعین کرتا ہے (کیا اور کیسے کرتے ہیں)، Daily ہم آہنگ کرتا ہے (کون کیا کر رہا ہے، کیا رکاوٹیں ہیں)، Review نتیجہ دکھاتا ہے (کیا کیا گیا، کیا نہیں کیا گیا)، Retrospective عمل کو بہتر بناتا ہے (اگلے سپرنٹ کو کیسے بہتر بنایا جائے)۔ Retrospective چھوڑنا سب سے عام ٹیم کی غلطی ہے: جب ڈیڈ لائن تنگ ہوتی ہیں، تو سب سے پہلے Retro کو قربان کیا جاتا ہے۔ یہ عمل کے جمود اور اسی غلطیوں کے تکرار کا باعث بنتا ہے۔ Scrum.org (2025) کی تحقیق سے پتہ چلتا ہے: ہر 2 ہفتے میں Retro کرنے والی ٹیمیں رفتار میں 35% تیزی سے بہتری لاتی ہیں۔

Sprint Planning: تکرار کی منصوبہ بندی

Sprint Planning سپرنٹ کے شروع میں ٹیم کی ایک میٹنگ ہے جس میں طے کیا جاتا ہے کہ کیا کیا جائے گا اور کیسے۔ Product Owner Product Backlog سے ترجیحی کام پیش کرتا ہے۔ ٹیم صلاحیت (چھٹیوں، میٹنگوں، تکنیکی قرض کو مدنظر رکھتے ہوئے دستیاب وقت) کا اندازہ لگاتی ہے اور ان کاموں کا انتخاب کرتی ہے جو سپرنٹ کے دوران مکمل کر سکتی ہے۔ Planning کا نتیجہ Sprint Goal (سپرنٹ کا مقصد) اور Sprint Backlog (کاموں کی فہرست) ہے۔ Sprint Goal ایک مختصر جملے کے طور پر وضع کیا جاتا ہے: «آرڈر اسکرین اور SBP کے ذریعے ادائیگی کا انضمام نافذ کریں۔»

رفتار (Velocity) فی سپرنٹ کہانی پوائنٹس میں ماپا جانے والی ٹیم کی رفتار ہے۔ پچھلے 3-5 سپرنٹ کی اوسط۔ Scrum.org (2025) کے مطابق، 5 موبائل ڈویلپرز (3 Android + 2 iOS) کی ایک ٹیم کی رفتار 2 ہفتے کے سپرنٹ کے لیے 25-40 SP ہے۔ Planning رفتار کو بالائی حد کے طور پر استعمال کرتا ہے — غیر متوقع کاموں (کوڈ کا جائزہ، واقعات، دوسری ٹیموں کی مدد) کے لیے 10-15% کم لیتے ہیں۔ صلاحیت بمقابلہ رفتار: صلاحیت «افراد-گھنٹے» ہے، رفتار «کہانی پوائنٹس» ہے۔ صلاحیت چھٹیوں، بیماری کی چھٹی، میٹنگوں کو مدنظر رکھتی ہے۔ عام نقصان کی شرح کام کے وقت کا 25-30% غیر کوڈ سرگرمیوں پر خرچ ہوتا ہے۔

Planning دو حصوں میں تقسیم ہے: «کیا» (PO کاموں کی وضاحت کرتا ہے، ٹیم واضح کرتی ہے) — 2 گھنٹے، اور «کیسے» (ٹیم تقسیم اور اندازہ لگاتی ہے) — 2 گھنٹے۔ موبائل منصوبوں کے لیے، «کیسے» میں بحث ہوتی ہے: Android/iOS ورژن کے ساتھ مطابقت، فیچر فلیگ کی ضرورت، APK/IPA سائز پر اثر، نئی اجازتیں۔ Planning Poker تکنیک اندازہ لگانے کے لیے استعمال ہوتی ہے: ہر ڈویلپر کہانی پوائنٹس (1, 2, 3, 5, 8, 13) میں اپنا اندازہ دیتا ہے۔ 2 یونٹ سے زیادہ کا فرق وجوہات پر بحث کو متحرک کرتا ہے۔ یہ سپرنٹ کے وسط میں نہیں بلکہ منصوبہ بندی کے مرحلے میں پوشیدہ خطرات کو ظاہر کرتا ہے۔

سپرنٹ پر عملدرآمد: Daily Standup اور ٹریکنگ

Daily Scrum (Standup) ٹیم کی ہم آہنگی کے لیے روزانہ 15 منٹ کی میٹنگ ہے۔ ہر شریک تین سوالوں کا جواب دیتا ہے: «کل کیا کیا گیا؟«، «آج کیا کرنے کا منصوبہ ہے؟«، «کیا رکاوٹیں ہیں؟« Daily مینیجر کے لیے اسٹیٹس رپورٹ نہیں ہے، بلکہ ٹیم کی خود تنظیم کا ایک ذریعہ ہے۔ اگر Daily میں پتہ چلتا ہے کہ دو ڈویلپر ایک ہی کام پر کام کر رہے ہیں — تو یہ تنظیم نو کا اشارہ ہے۔ اہم: Daily مسائل حل نہیں کرتا بلکہ ان کی نشاندہی کرتا ہے — حل کے لیے Daily کے بعد علیحدہ میٹنگ بلائی جاتی ہے۔

Scrum Board (سپرنٹ بورڈ) Sprint Backlog کی بصری نمائندگی ہے۔ کالم: To Do / In Progress / In Review / Done۔ ہر کام بورڈ پر منتقل ہوتا ہے۔ Burndown Chart سپرنٹ کے دنوں کے مطابق باقی کام کا گراف ہے۔ مثالی برن ڈاؤن کل SP سے 0 تک ایک سیدھی لکیر ہے۔ حقیقی برن ڈاؤن کام کی تکمیل کو مدنظر رکھتے ہوئے ایک سیڑھی دار گراف ہے۔ نیچے گرتا ہوا برن ڈاؤن (مثالی لکیر سے نیچے) کا مطلب ہے کہ ہم پیچھے ہیں۔ مسئلہ کا اشارہ: اگر سپرنٹ کے وسط تک 30% سے کم کام مکمل ہوئے ہیں — ایڈجسٹمنٹ ضروری ہے۔ ہو سکتا ہے خطرات پر غور نہیں کیا گیا یا کاموں کا زیادہ اندازہ لگایا گیا۔

موبائل ڈویلپمنٹ کے لیے، سپرنٹ ٹریکنگ مخصوص عوامل سے متاثر ہوتی ہے: بلڈ کا وقت (CI میں Android پروجیکٹ بلڈ میں 30+ منٹ لگ سکتے ہیں)، App Store / Google Play کی منظوری کا انتظار (اگر TestFlight کے ذریعے ٹیسٹرز کو بلڈ جاری کرنے کی ضرورت ہو)، مختلف آلات کے ساتھ مطابقت (10+ ماڈلز پر ٹیسٹ میں وقت لگتا ہے)۔ مشورہ: حتمی جانچ اور ریلیز بلڈ اسمبلی کے لیے سپرنٹ کے آخر میں 1 دن کا بفر مختص کریں۔ یہ Mind the Product (2025) کے مطابق نامکمل سپرنٹ کے خطرے کو 40% کم کرتا ہے۔

Sprint Review اور Retrospective

Sprint Review اسٹیک ہولڈرز کو اضافہ کا مظاہرہ ہے۔ ٹیم سلائیڈز نہیں بلکہ ایک کام کرنے والا ایپلیکیشن بلڈ دکھاتی ہے۔ 2 ہفتے کے سپرنٹ کے لیے مدت 2 گھنٹے ہے۔ Product Owner Acceptance Criteria کی تعمیل کو چیک کرتا ہے۔ اسٹیک ہولڈرز رائے فراہم کرتے ہیں جو Product Backlog کو متاثر کر سکتی ہے۔ Review رپورٹ نہیں بلکہ مکالمہ ہے: اسٹیک ہولڈرز سوال پوچھ سکتے ہیں اور تبدیلیاں تجویز کر سکتے ہیں۔ اہم اصول: Sprint Review عمل کے بارے میں نہیں، مصنوعات کے بارے میں ہے۔ دکھائیں کہ کیا حاصل کیا گیا، نہ کہ کیسے کیا گیا۔

Sprint Retrospective گزشتہ سپرنٹ کا تجزیہ کرنے کے لیے اندرونی ٹیم میٹنگ ہے۔ فارمیٹ: Start Doing (کیا شروع کریں)، Stop Doing (کیا بند کریں)، Continue Doing (کیا جاری رکھیں)۔ 2 ہفتے کے سپرنٹ کے لیے مدت 1.5 گھنٹے ہے۔ Retrospective مسائل پر بحث کے لیے ایک محفوظ جگہ ہے۔ اصول: Retro میں تکنیکی تفصیلات پر بحث نہیں کی جاتی (اس کے لیے تکنیکی میٹنگیں ہیں)۔ صرف عمل، مواصلات، اوزار، ثقافت۔ Scrum Master میٹنگ میں سہولت فراہم کرتا ہے اور یقینی بناتا ہے کہ ہر شریک بولے۔

Retrospective کا نتیجہ اگلے سپرنٹ کے لیے 1-3 بہتری ہیں۔ اگر ٹیم نے «کوڈ کا جائزہ بہت زیادہ وقت لیتا ہے» کا مسئلہ شناخت کیا — ایکشن آئٹم: «جائزے کے لیے SLA مقرر کریں — 4 گھنٹے۔ اگر جائزہ وقت پر نہیں کیا جاتا — ڈویلپر Slack میں یاد دہانی کرائے گا۔» ایکشن آئٹمز مخصوص، قابل پیمائش اور کسی مخصوص شخص کو تفویض ہونے چاہئیں۔ Atlassian (2025) کے مطابق، جو ٹیمیں اپنے Retro ایکشن آئٹمز کو مکمل کرتی ہیں، وہ 3-4 سپرنٹ میں رفتار میں 15-25% بہتری لاتی ہیں۔ جو نہیں کرتیں — وہ جمود کا شکار رہتی ہیں۔

سپرنٹ کی مدت کیسے منتخب کریں

2 ہفتے موبائل ڈویلپمنٹ کے لیے معیاری ہیں۔ پیشین گوئی اور لچک کے درمیان بہترین توازن۔ کافی وقت: منصوبہ بندی کرنے، 3-5 درمیانی خصوصیات کو نافذ کرنے، جانچ کرنے، نتائج دکھانے کے لیے۔ 1 ہفتہ اعلیٰ عمل پختگی اور CI/CD والی ٹیموں کے لیے ہے۔ فوری فیصلوں، کم سے کم بیوروکریسی کی ضرورت ہے۔ ابتدائی مرحلے کے اسٹارٹ اپس کے لیے موزوں جنہیں تیزی سے تجربہ کرنے کی ضرورت ہے۔ نقصان: رسومات پر زیادہ اوور ہیڈ (ہر ہفتے Planning + Review + Retro = 7.5 گھنٹے)۔

3-4 ہفتے پیچیدہ منصوبوں کے لیے ہیں جن میں ہارڈویئر انضمام (wearables, IoT, BLE آلات)، طویل اسٹور کی منظوری یا بڑی منتقلی (مثال کے طور پر، RxJava سے Coroutines میں منتقلی) شامل ہے۔ لمبے سپرنٹ جانچ کے لیے زیادہ وقت دیتے ہیں لیکن «آبشار اثر» کا خطرہ بڑھاتے ہیں — ٹیم Agile لچک کھو دیتی ہے۔ Scrum Guide کی سفارش: 1 ماہ سے تجاوز نہ کریں۔ اگر سپرنٹ لمبا ہے تو Review میں بہت زیادہ سیاق و سباق ہوگا اور اسٹیک ہولڈرز معیاری رائے نہیں دے سکیں گے۔

سپرنٹ کے عام مسائل

مسئلہ 1: دائرہ کار میں توسیع (Scope Creep)۔ سپرنٹ کے وسط میں، Product Owner ایک نیا «فوری اور اہم» کام شامل کرتا ہے۔ ٹیم اتفاق کرتی ہے — اور سپرنٹ ناکام ہو جاتا ہے۔ حل: Sprint Goal ایک معاہدہ ہے۔ کسی بھی تبدیلی کے لیے Sprint Goal پر نظرثانی کی ضرورت ہوتی ہے، جو صرف ہنگامی صورتوں میں ممکن ہے۔ نیا کام Product Backlog اور اگلے سپرنٹ میں جاتا ہے۔ اگر کام واقعی اہم ہے — پرانا Sprint Goal منسوخ کر دیا جاتا ہے، سپرنٹ کی دوبارہ منصوبہ بندی کی جاتی ہے، لیکن یہ استثنا ہے، عمل نہیں۔ 3 سپرنٹ میں ایک بار سے زیادہ دائرہ کار میں توسیع کمزور Product Owner کی علامت ہے۔

مسئلہ 2: نامکمل کام۔ سپرنٹ کے اختتام پر، 50% کام In Progress، 20% In Review، صرف 30% Done ہیں۔ وجوہات: زیادہ اندازہ لگائی گئی صلاحیت، کم اندازہ لگائی گئی پیچیدگی، غیر منصوبہ بند بگز۔ حل: Retro میں وجہ کا تجزیہ کریں۔ اگر آپ منظم طریقے سے نہیں پکڑ سکتے — Planning میں کاموں کی تعداد نہ بڑھائیں، بلکہ کم کریں۔ جو ٹیمیں 20% کم کام لیتی ہیں، وہ زیادہ تکمیل کی شرح دکھاتی ہیں (80%+ بمقابلہ 50-60%)۔ Planning کے لیے چیک لسٹ: ہر کام کے لیے Acceptance Criteria، Definition of Ready اور دوسرے کاموں کے ساتھ انحصار چیک کریں۔

مسئلہ 3: رسمی Retro۔ ٹیم صرف دکھاوے کے لیے Retro کرتی ہے — 15 منٹ، عام جملے، کوئی ایکشن آئٹم نہیں۔ حل: ہر Retro کا فارمیٹ تبدیل کریں۔ طریقے: Sailboat (کیا سست کرتا ہے، کیا تیز کرتا ہے)، Start / Stop / Continue، Happy / Sad / Mad، 4Ls (Liked, Learned, Lacked, Longed For)۔ ڈیڈ لائن اور ذمہ دار افراد کے ساتھ ایکشن آئٹم تفویض کریں۔ اگلے Retro کے شروع میں، پچھلے ایکشن آئٹمز کی تکمیل چیک کریں۔ Atlassian (2025) کے مطابق، مختلف Retro فارمیٹ استعمال کرنے والی ٹیمیں 50% زیادہ مفید بصیرت پیدا کرتی ہیں۔