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

ٹاسک گروومنگ کیا ہے؟

Backlog Grooming (refinement) — پروڈکٹ بیک لاگ کے ٹاسکس کو آئندہ سپرنٹس کے لیے تیار کرنے کا عمل۔ ایک میٹنگ جس میں پروڈکٹ اونر اور ڈویلپمنٹ ٹیم ٹاسکس کا جائزہ لیتے ہیں: ضروریات کی وضاحت کرتے ہیں، Acceptance Criteria شامل کرتے ہیں، پیچیدگی کا اندازہ لگاتے ہیں، انحصار اور خطرات کی نشاندہی کرتے ہیں۔ Scrum Guide میں گروومنگ کو لازمی ایونٹ نہیں سمجھا جاتا — یہ ایک اضافی مشق ہے جسے Scrum ٹیمیں Sprint Planning میں غیر یقینی صورتحال کم کرنے کے لیے اپناتی ہیں۔ تجویز کردہ تعدد — فی سپرنٹ 1 بار، زیادہ سے زیادہ 60 منٹ۔

اصطلاح "کنگھی کرنا" (grooming) اس کے جوہر کو ظاہر کرتی ہے: ٹیم بیک لاگ کو "کنگھی" کرتی ہے، متروک ٹاسکس ہٹاتی ہے، غیر واضح کو واضح کرتی ہے اور بہت بڑے ٹاسکس کو توڑتی ہے۔ موبائل ڈویلپمنٹ میں گروومنگ خاص طور پر اہم ہے کیونکہ پلیٹ فارم کی مخصوصیت: Android کا ٹاسک iOS ورژن سے پیچیدگی میں مختلف ہو سکتا ہے، targetSdk، compileSdk، API سطحوں کے ساتھ مطابقت کو مدنظر رکھنا ہوتا ہے۔ گروومنگ کے بغیر Sprint Planning افراتفری میں بدل جاتا ہے: ٹیم پہلی بار ٹاسک دیکھتی ہے اور ان کا تخمینہ نہیں لگا سکتی، جس سے غیر متوقع صورتحال اور ڈیڈ لائن کی خلاف ورزی ہوتی ہے۔

گروومنگ کا نتیجہ — کئی ٹاسک جو Sprint Planning کے لیے تیار ہیں: ان میں تفصیل، Acceptance Criteria، تخمینہ ہے اور وہ Definition of Ready پر پورا اترتے ہیں۔ پروڈکٹ اونر کو ترجیح کی ترتیب میں ٹاسکس کو گرووم کرنا چاہیے: موجودہ سپرنٹ کے قریب ترین — سب سے زیادہ تفصیلی۔ 3-4 سپرنٹ آگے کے ٹاسک — صرف ایپک کی سطح پر۔ Progressive Refinement تکنیک: ٹاسک جتنا سپرنٹ کے قریب ہو، اس کی تفصیل اتنی ہی زیادہ۔ موجودہ سپرنٹ کے ٹاسکس کے لیے — مکمل ریفائنمنٹ (AC، ڈیزائن، API اسپیسیفکیشن)۔ 2 سپرنٹ آگے کے ٹاسکس کے لیے — story-level (user story بغیر نفاذ کی تفصیلات کے)۔ 3+ سپرنٹ آگے کے ٹاسکس کے لیے — epic-level (صرف نام اور کاروباری قدر)۔

Definition of Ready: ٹاسک کب سپرنٹ کے لیے تیار ہے

Definition of Ready (DoR) — معیاروں کی ایک چیک لسٹ جن پر ٹاسک کو Sprint Backlog میں شامل کرنے سے پہلے پورا اترنا چاہیے۔ DoR پروڈکٹ اونر اور ٹیم کے درمیان ایک معاہدہ ہے: PO ضمانت دیتا ہے کہ ڈویلپمنٹ کے لیے تمام معلومات موجود ہیں، ٹیم ضمانت دیتی ہے کہ وہ ٹاسک کا تخمینہ لگا سکتی ہے اور اسے مکمل کر سکتی ہے۔ DoR عالمگیر نہیں — ہر ٹیم اپنے معیار کا سیٹ متعین کرتی ہے۔ DoR کے بغیر ٹاسک غیر واضح ضروریات کے ساتھ سپرنٹ میں آ سکتا ہے، جس سے دوبارہ کام اور ڈیڈ لائن کی خلاف ورزی ہوتی ہے۔

موبائل ڈویلپمنٹ کے لیے عام DoR: 1) Acceptance Criteria بیان کردہ (Given-When-Then فارمیٹ میں قبولیت کے معیار)۔ 2) Figma میں ڈیزائن مکمل (UI ٹاسکس کے لیے) تمام حالتوں کے ساتھ: default، loading، error، empty state۔ 3) API اسپیسیفکیشن منظور شدہ (OpenAPI/Swagger، درخواستوں اور جوابات کی مثالیں)۔ 4) اسٹوری پوائنٹس میں تخمینہ موجود۔ 5) دوسرے ٹاسکس پر انحصار کی نشاندہی کی گئی۔ 6) ٹاسک نامکمل بیرونی اجزاء پر منحصر نہیں۔ 7) موبائل مخصوص: OS کے ہدف والے ورژن، فیچر فلیگ کی ضرورت، پرانے API سطحوں کی سپورٹ متعین۔

ٹاسکس کے تخمینہ کی تکنیکیں

Planning Poker — گروومنگ پر تخمینہ لگانے کی سب سے مقبول تکنیک۔ ہر ڈویلپر کو فبونیکی نمبروں (1, 2, 3, 5, 8, 13, 21) والے کارڈز کا ایک ڈیک ملتا ہے۔ PO ٹاسک دکھاتا ہے اور اس کی وضاحت کرتا ہے۔ بحث کے بعد سب بیک وقت کارڈ دکھاتے ہیں۔ اگر تخمینے بہت مختلف ہوں (مثلاً 3 اور 13) — ڈویلپر اپنے تخمینے کی وجہ بتاتے ہیں، پھر دوبارہ ووٹ دیتے ہیں۔ مراحل متفقہ رائے تک دہرائے جاتے ہیں۔ Planning Poker کا مقصد درست تخمینہ نہیں، بلکہ ٹاسک کی سمجھ میں فرق کو ظاہر کرنا ہے۔

T-Shirt Sizing — فوری تخمینہ کے لیے آسان تکنیک: XS (1 SP)، S (2)، M (3)، L (5)، XL (8)، XXL (13)۔ بیک لاگ کی ابتدائی ترتیب کے لیے موزوں جب بہت سے ٹاسک ہوں اور ان کی شدت کا تیزی سے اندازہ لگانا ہو۔ T-Shirt Sizing کے بعد اگلے سپرنٹ کے ٹاسکس کے لیے Planning Poker کے ذریعے زیادہ درست تخمینہ لگایا جاتا ہے۔ Affinity Estimation — بغیر نمبروں کے ٹاسکس کی نسبتاً پیچیدگی کے مطابق گروپ بندی؛ ٹاسک میز پر آسان سے مشکل تک رکھے جاتے ہیں، پھر کلسٹرز میں گروپ کیے جاتے ہیں، ہر کلسٹر کو تخمینہ ملتا ہے۔

موبائل ڈویلپمنٹ میں تخمینہ میں پلیٹ فارم کی پیچیدگی کو مدنظر رکھنا چاہیے۔ Android کا ٹاسک 5 SP کا ہو سکتا ہے جبکہ وہی iOS ٹاسک 3 SP کا (یا اس کے برعکس)۔ یہ معمول ہے: مختلف پلیٹ فارمز پر نفاذ کی پیچیدگی مختلف ہوتی ہے۔ مشورہ: اگر ٹیم کراس پلیٹ فارم ہے تو ہر پلیٹ فارم کا الگ تخمینہ لگائیں۔ نسبتاً پیمانہ استعمال کریں: بنیادی ٹاسک (مثلاً متن اور بٹن والی اسکرین) = 1 SP۔ باقی سب اس کے نسبتاً۔ Scrum.org (2025) کے مطابق، 3-4 سپرنٹس کے بعد ٹیم کے تخمینے کی درستگی ±20% اصل پیچیدگی تک پہنچ جاتی ہے۔

تقسیم: بڑے ٹاسکس کو کیسے توڑیں

8 SP سے بڑے ٹاسکس کو چھوٹے حصوں میں تقسیم کیا جانا چاہیے۔ بڑے ٹاسک ایک سپرنٹ میں مکمل نہیں ہو سکتے، ان کا تخمینہ لگانا مشکل ہے، اور وہ پیشرفت کا احساس نہیں دیتے۔ تقسیم کی تکنیک: ٹاسک کو افقی تہوں (UI → ViewModel → Repository → Network/DB) یا عمودی سلائسز (فیچر: ایک پوری اسکرین) میں تقسیم کریں۔ افقی تقسیم موبائل ڈویلپمنٹ کے لیے زیادہ موزوں ہے: Sub-task 1 — UI تیار کرنا (XML/Jetpack Compose/SwiftUI)، Sub-task 2 — ViewModel + State، Sub-task 3 — Repository + Network، Sub-task 4 — Unit ٹیسٹ۔

عمودی تقسیم — یوزر اسٹوری کو چھوٹی آزاد قدر والی کہانیوں میں کاٹنا۔ مثال: Epic "خریداری کی ٹوکری" → Story 1 "ٹوکری میں پروڈکٹ شامل کرنا"، Story 2 "ٹوکری دکھانا"، Story 3 "ٹوکری سے پروڈکٹ ہٹانا"، Story 4 "آرڈر دینا"۔ ہر Story کی اپنی کاروباری قدر ہوتی ہے اور اسے آزادانہ طور پر جاری کیا جا سکتا ہے۔ SPoK (Story Points on Kano): Stories کو کاروباری قدر کے مطابق درجہ بندی کریں (Must-have، Should-have، Could-have) اور قدر کی ترتیب میں نافذ کریں۔

گروومنگ پر تقسیم کی چیک لسٹ: 1) کیا ٹاسک 8 SP سے بڑا ہے؟ → تقسیم کریں۔ 2) کیا Acceptance Criteria موجود ہیں؟ → اگر نہیں تو شامل کریں۔ 3) کیا دوسرے ٹاسکس پر منحصر ہے؟ → انحصار کی نشاندہی اور ریکارڈ کریں۔ 4) کیا غیر یقینی صورتحال ہے؟ → مین ٹاسک سے پہلے Spike (تحقیق) شامل کریں۔ 5) کیا ڈیزائن ضروری ہے؟ → مکٹ کی تیاری چیک کریں۔ INVEST اصول: Independent (دوسروں سے آزاد)، Negotiable (قابل بحث)، Valuable (کاروبار کے لیے قیمتی)، Estimable (قابل تخمینہ)، Small (چھوٹا)، Testable (قابل جانچ)۔ اگر ٹاسک INVEST پر پورا نہیں اترتا — تو یہ سپرنٹ کے لیے تیار نہیں۔

گروومنگ کا عمل: قدم بہ قدم

قدم 1: وارم اپ (5 منٹ)۔ Scrum Master گروومنگ اور DoR کے مقصد کی یاد دہانی کراتا ہے۔ ٹیم بورڈ دیکھتی ہے، PO بتاتا ہے کہ کن ٹاسکس پر بحث ہوگی۔ قدم 2: ٹاسکس کا جائزہ (30 منٹ)۔ PO موجودہ سپرنٹ کے آخر اور اگلے سپرنٹ کے شروع کے ٹاسکس پیش کرتا ہے۔ ہر ٹاسک کے لیے: نام، تفصیل، Acceptance Criteria (اگر موجود)، ڈیزائن کا لنک، API اسپیسیفکیشن۔ ٹیم وضاحتی سوالات پوچھتی ہے: "کیا خالی حالت کے لیے مکٹ ہے؟"، "HTTP طریقہ کیا ہے؟"، "iOS minimum deployment target کیا ہے؟"۔

قدم 3: تخمینہ (15 منٹ)۔ ٹیم Planning Poker یا T-Shirt Sizing کے ذریعے ٹاسک کا تخمینہ لگاتی ہے۔ اگر فرق > 2 SP ہے — وجوہات پر بحث کرتے ہیں اور دوبارہ ووٹ دیتے ہیں۔ اصول: اگر ٹاسک کا تخمینہ نہیں لگایا جا سکتا (ضروریات واضح نہیں، ڈیزائن نہیں) — یہ PO کی نظرثانی کے لیے واپس جاتا ہے اور اگلے گروومنگ میں وضاحت کے ساتھ آئے گا۔ نامعلوم چیزوں والے ٹاسکس کا تخمینہ نہ لگائیں — یہ یقینی طور پر سپرنٹ میں غلطی کا باعث بنے گا۔ قدم 4: نتائج ریکارڈ کرنا (10 منٹ)۔ PO Jira/Linear میں تخمینے ریکارڈ کرتا ہے، ٹاسک کی تفصیل اپ ڈیٹ کرتا ہے اور ترجیحات طے کرتا ہے۔

گروومنگ کے نتائج: 3-7 مکمل طور پر Sprint Planning کے لیے تیار ٹاسک (DoR، تخمینہ، ڈیزائن، API کے ساتھ)۔ PO بیک لاگ اپ ڈیٹ کرتا ہے: متروک ٹاسک ہٹاتا ہے، ڈپلیکیٹ ملاتا ہے، ترجیحات واضح کرتا ہے۔ اہم: گروومنگ PO کا کام ختم نہیں کرتی — گروومنگ کے درمیان وہ اگلے ٹاسک تیار کرے۔ تجویز کردہ رفتار: PO گروومنگ کے لیے 3-4 ٹاسک تیار کرتا ہے، ٹیم ان پر کام کرتی ہے۔ اگر بیک لاگ میں 50 سے زیادہ ٹاسک ہیں — PO کو گروومنگ سے پہلے ترجیح دینی چاہیے (MoSCoW یا Weighted Shortest Job First)۔

گروومنگ Sprint Planning سے کیسے مختلف ہے

گروومنگ — تیاری ہے۔ اس پر کوئی ذمہ داری نہیں — ٹاسک صرف واضح اور تخمینہ لگایا جاتا ہے۔ Sprint Planning — ذمہ داری ہے۔ ٹیم گروومنگ پر تیار کردہ ٹاسکس میں سے انتخاب کرتی ہے اور انہیں سپرنٹ میں مکمل کرنے کی ذمہ داری لیتی ہے۔ بنیادی فرق: گروومنگ کسی مخصوص سپرنٹ سے منسلک نہیں (بیک لاگ کا عمومی ریفائنمنٹ)، گروومنگ پر Sprint Goal نہیں ہوتا، گروومنگ سپرنٹ کے کسی بھی وقت ہو سکتی ہے۔ Sprint Planning — سختی سے سپرنٹ کے شروع میں اور ہمیشہ Sprint Goal کا تعین کرتا ہے۔

گروومنگ پر ٹاسک صرف تخمینہ لگائے جاتے ہیں، لیکن سپرنٹ میں نہیں لیے جاتے۔ Planning پر ٹاسک تیار پول سے منتخب کیے جاتے ہیں۔ گروومنگ کے بغیر Sprint Planning 6-8 گھنٹے لیتا ہے (بجائے 4 کے) کیونکہ ٹیم پہلی بار ٹاسک دیکھتی ہے اور فوری تخمینہ نہیں لگا سکتی۔ 80/20 اصول: Sprint Planning پر 80% ٹاسک مکمل طور پر تیار ہونے چاہئیں (گروومنگ سے گزرے)، 20% — نئے ہو سکتے ہیں (فوری بگز، hotfix)۔ اگر Planning پر 20% سے زیادہ بغیر تخمینہ والے ٹاسک ہیں — گروومنگ ناکافی تھی۔

گروومنگ کی عام غلطیاں

غلطی 1: مہینے میں ایک بار گروومنگ۔ ٹیم 3-4 سپرنٹ کے ٹاسک جمع کرتی ہے، 2 گھنٹے میں سب کچھ واضح کرنے کی کوشش کرتی ہے۔ نتیجہ: آدھے ٹاسک بغیر تخمینہ کے رہ جاتے ہیں، Planning پورا دن لیتا ہے۔ حل: گروومنگ باقاعدہ ہونی چاہیے — فی سپرنٹ 1 بار، 60 منٹ۔ اگر ٹاسک زیادہ ہیں — سپرنٹ کے وسط میں دوسری گروومنگ شامل کریں۔ بہتر ہے کہ کم ٹاسک گرووم کریں لیکن معیاری طور پر، بجائے زیادہ لیکن سطحی طور پر۔ رفتار: ایک گروومنگ میں 3-5 ٹاسک، ہر ایک کو مکمل بحث اور تخمینہ ملتا ہے۔

غلطی 2: بغیر سیاق و سباق کے تخمینہ۔ PO ٹاسک دکھاتا ہے "خریداری کی ٹوکری کی اسکرین بنائیں" بغیر ڈیزائن، API، AC کے۔ ٹیم "اندازاً" تخمینہ لگاتی ہے — 13 SP۔ Planning میں پتہ چلتا ہے کہ یہ دراصل 5 SP ہے (کیونکہ اسکرین سادہ ہے)۔ حل: ٹاسک کا تخمینہ نہیں لگایا جاتا اگر ڈیزائن یا API نہ ہو۔ PO گروومنگ سے پہلے مواد تیار کرنے کا پابند ہے۔ اصول: "مکٹ نہیں — تخمینہ نہیں"۔ استثنا: Spike ٹاسک — غیر یقینی صورتحال کی تحقیق، ان کا تخمینہ ڈیزائن کے بغیر الگ سے لگایا جاتا ہے (تحقیق کی پیچیدگی کے لحاظ سے 2-5 SP)۔

غلطی 3: گروومنگ Planning میں بدل جاتی ہے۔ ٹیم ٹاسک ڈویلپرز میں تقسیم کرنا شروع کر دیتی ہے اور بحث کرتی ہے کہ کون کیا کرے گا۔ حل: یاد دلائیں کہ گروومنگ وضاحت کے لیے ہے، تقسیم کے لیے نہیں۔ تقسیم — سپرنٹ شروع ہونے کے بعد Daily میں۔ گروومنگ سوال کا جواب دیتی ہے "کیا کرنا ہے؟"، Planning — "کب کرنا ہے؟"، Daily — "کون کر رہا ہے؟"۔ ایک میٹنگ میں ان سوالات کا اختلاط ہر ایک کی تاثیر کم کرتا ہے۔ Scrum Master کو Planning بحث روک کر ٹاسک کی وضاحت پر توجہ مرکوز کرنی چاہیے۔

غلطی 4: Tech Debt کو نظر انداز کرنا۔ گروومنگ پر صرف نئے فیچرز پر بحث ہوتی ہے، تکنیکی ٹاسکس کو نظر انداز کیا جاتا ہے۔ 3-4 سپرنٹ کے بعد تکنیکی قرضہ خطرناک سطح تک پہنچ جاتا ہے۔ حل: ہر گروومنگ پر کم از کم 1 Tech ٹاسک کا تخمینہ لگنا چاہیے۔ تناسب: 3 فیچرز پر → 1 Tech ٹاسک۔ Tech Debt Ratio میٹرک استعمال کریں: سپرنٹ میں Tech ٹاسکس کا Feature ٹاسکس سے تناسب۔ ہدف: 0.25-0.3 (25-30% وقت Tech Debt پر)۔ اگر ratio 0.2 سے کم ہے — اگلے سپرنٹس میں ڈویلپمنٹ کی رفتار گر جائے گی۔