User Stories کیسے لکھیں (مثالوں اور acceptance criteria کے ساتھ)

user story فیچر کا ایک مختصر بیان ہے، صارف کے نقطۂ نظر سے: “بطور [صارف کی قسم]، میں [مقصد] چاہتا ہوں تاکہ [وجہ]۔” اس کے نیچے acceptance criteria لکھیں، یعنی چند مخصوص شرائط جو سچ ہونی چاہئیں تاکہ story مکمل سمجھی جائے۔ ہر story اتنی چھوٹی رکھیں کہ ایک بار میں بنائی اور جانچی جا سکے، اور criteria ایسے لکھیں کہ کوئی بھی انہیں پرکھ سکے۔

User stories کو ایجائل سافٹ ویئر ٹیموں نے مقبول کیا، مگر جب آپ AI ایپ بلڈر کے ساتھ اکیلے بنا رہے ہوں تو یہ اتنی ہی مفید ہیں۔ ایک اچھی story ایک اچھا پرامپٹ ہے۔

فارمیٹ

ایک user story کے تین حصے ہوتے ہیں:

بطور [کون]، میں چاہتا ہوں [کیا] تاکہ [کیوں]۔

• کون ایک مخصوص قسم کا صارف ہے: پہلی بار آنے والا وزیٹر، ادائیگی کرنے والا ممبر، کلینک کا ریسیپشنسٹ، ایڈمن۔ “صارف” نہیں۔
• کیا وہ چیز ہے جو وہ کرنا چاہتا ہے، ان کے اپنے الفاظ میں۔ اسکرین کیسے کام کرتی ہے یہ نہیں۔
• کیوں وہ نتیجہ ہے جس کی انہیں پروا ہے۔ یہی وہ حصہ ہے جسے لوگ چھوڑ دیتے ہیں، اور یہی آپ کو غلط چیز بنانے سے روکتا ہے۔

مثال:

بطور جم ممبر، میں اپنے فون سے کلاس بکنگ منسوخ کرنا چاہتا ہوں تاکہ ویٹ لسٹ پر کوئی اور میری جگہ لے سکے اور مجھ سے نو-شو فیس نہ لی جائے۔

“کیوں” آپ کو دو ایسی باتیں بتاتا ہے جو “کیا” نہیں بتاتا: یہ فون پر کام کرنا چاہیے، اور ویٹ لسٹ اور فیس کے اصول اس میں شامل ہیں۔

Acceptance criteria

Story بتاتی ہے کہ کیا چاہیے۔ Acceptance criteria بتاتے ہیں کہ کام مکمل کب ہوا۔ یہ اتنے مخصوص ہونے چاہئیں کہ دو لوگ متفق ہو سکیں کہ ہر ایک پاس ہوتی ہے یا نہیں۔

ان کو لکھنے کا ایک عام طریقہ Given / When / Then ہے:

• Given ایک ابتدائی صورتحال
• When صارف کچھ کرے
• Then یہ نتیجہ ہو

جم بکنگ والی story کے لیے:

1. Given میری بکنگ 12 گھنٹے سے زیادہ دور ہے، when میں Cancel پر ٹیپ کروں اور تصدیق کروں، then بکنگ ہٹ جائے اور مجھے “Booking cancelled” نظر آئے۔
2. Given میں ایک بکنگ منسوخ کرتا ہوں اور کلاس میں ویٹ لسٹ ہے، when منسوخی محفوظ ہو، then ویٹ لسٹ پر پہلے شخص کو جگہ اور ای میل ملے۔
3. Given بکنگ 12 گھنٹے سے کم دور ہے، when میں Cancel ٹیپ کروں، then تصدیق سے پہلے مجھے دکھائی دے کہ دیر سے منسوخی کی فیس لاگو ہوتی ہے۔
4. Given میں فون کی چوڑائی والی اسکرین پر ہوں، then Cancel بٹن بغیر افقی اسکرول کے نظر آئے۔

ایک سادہ چیک لسٹ بھی کام کرتی ہے، بشرطیکہ ہر آئٹم قابلِ جانچ ہو۔ “منسوخی آسان ہے” قابلِ جانچ نہیں۔ “بکنگ کی فہرست سے منسوخی زیادہ سے زیادہ دو ٹیپ میں ہو” قابلِ جانچ ہے۔

قدم بہ قدم: اچھی story لکھنا

قدم 1: ایک حقیقی صارف اور ایک حقیقی مسئلے سے شروع کریں

صارف کی ایک قسم اور وہ مسئلہ چنیں جو انہیں آج درپیش ہے۔ اگر آپ نے گاہکوں کے انٹرویوز کیے ہیں تو ان کے اپنے الفاظ استعمال کریں۔ “میں منسوخ کرنا بھول جاتا ہوں اور چارج ہو جاتا ہوں” “کینسلیشن فیچر شامل کریں” سے بہتر نقطۂ آغاز ہے۔

قدم 2: ایک لائن کی story لکھیں

ٹیمپلیٹ بھریں۔ اگر آپ “تاکہ” والا حصہ قائل کرنے والے انداز میں نہیں لکھ سکتے تو پوچھیں کہ کیا فیچر کی ضرورت ہی ہے۔

قدم 3: تین سے چھ acceptance criteria شامل کریں

پہلے بنیادی کامیاب صورت کا احاطہ کریں، پھر اہم تبدیلیاں: ایک مختلف کردار، خالی حالت، کوئی حد، یا کوئی غلطی۔ اگر آپ چھ سے زیادہ لکھ رہے ہیں تو story شاید بہت بڑی ہے۔

قدم 4: لکھیں کہ کیا دائرے سے باہر ہے

ایک لائن بہت سی بحث بچاتی ہے: “دائرے سے باہر: کلاس کی ادا شدہ فیس کی واپسی؛ ایڈمن کا ممبرز کی جانب سے منسوخی کرنا۔” یہ بناتے وقت story کو بڑھنے سے روکتی ہے۔

قدم 5: INVEST سے جانچیں

INVEST اچھی stories کے لیے ایک عام چیک لسٹ ہے۔ ایک story ایسی ہونی چاہیے:

آپ کو ہر story کو نمبر دینے کی ضرورت نہیں۔ یہ سب سے زیادہ تب مفید ہے جب کوئی story غلط لگے اور آپ جاننا چاہیں کہ کیوں۔

اچھی اور بری مثالیں

بڑی story کو کیسے تقسیم کریں

بڑی stories وہی جگہ ہیں جہاں پروجیکٹ رکتے ہیں۔ تقسیم کے عام طریقے:

• صارف کے کردار کے مطابق۔ ممبرز اپنی بکنگز منسوخ کرتے ہیں؛ عملہ کسی کی بھی منسوخ کرتا ہے۔
• فلو کے مرحلے کے مطابق۔ کلاسز براؤز کریں؛ کلاس بک کریں؛ یاددہانی حاصل کریں۔
• پہلے سادہ کیس۔ ایک مفت کلاس ابھی منسوخ کریں؛ فیس اور رقم کی واپسی ایک بعد کی story میں سنبھالیں۔
• ڈیٹا کی تبدیلی کے مطابق۔ پہلے ایک مقام کو سپورٹ کریں، بعد میں کئی۔
• پہلے ہیپی پاتھ، پھر غلطیاں۔ پہلے اسے کام کرتا بنائیں، پھر بھری ہوئی کلاسوں، ختم شدہ پاسز وغیرہ کو سنبھالنے کا طریقہ شامل کریں۔

ہر ٹکڑا پھر بھی ایسا ہونا چاہیے جسے صارف استعمال کر سکے اور محسوس کرے۔

user stories کو پرامپٹس کے طور پر استعمال کرنا

acceptance criteria والی user story AI ایپ بلڈر کے لیے ایک اچھے پرامپٹ کے بہت قریب ہے۔ اس میں AI کو کس کے لیے، کیا، کیوں اور “مکمل” کی تعریف مل جاتی ہے۔ ہر پیغام میں ایک story بھیجیں:

بطور جم ممبر، میں اپنے فون سے کلاس بکنگ منسوخ کرنا چاہتا ہوں تاکہ ویٹ لسٹ پر کوئی میری جگہ لے سکے۔ Acceptance criteria:

1. منسوخی My Bookings میں ہر بکنگ پر ہو، تصدیقی مرحلے کے ساتھ۔
2. کلاس سے 12 گھنٹے سے زیادہ پہلے منسوخی صرف بکنگ ہٹا دے۔
3. 12 گھنٹے سے کم پہلے، تصدیق سے پہلے “A late-cancellation fee of $5 applies” دکھائیں، اور فیس بکنگ پر ریکارڈ کریں۔
4. اگر کلاس میں ویٹ لسٹ ہو تو پہلے شخص کو جگہ اور ای میل ملے۔
5. فون کی چوڑائی والی اسکرین پر کام کرے۔ دائرے سے باہر: رقم کی واپسی، عملے کا ممبرز کی جانب سے منسوخی۔ اسے بناؤ، پھر پریویو میں ہر criterion جانچو اور بتاؤ کہ کون سے پاس ہوئے۔

آپ AI سے یہ بھی کہہ سکتے ہیں کہ ایک کچے خیال سے stories کا ڈرافٹ بنائے، پھر خود اس میں ترمیم کریں:

میری ایپ کا خیال یہ ہے: [دو یا تین جملے]۔ پہلے ورژن کے لیے user stories لکھیں، صارف کی قسم کے مطابق گروپ کر کے، ہر ایک کے ساتھ 3 سے 5 Given/When/Then acceptance criteria۔ بتائیں کہ کون سی لانچ کے لیے لازمی ہیں اور کون سی انتظار کر سکتی ہیں۔

ہمیشہ نتیجے کو پڑھیں اور اس میں ترمیم کریں۔ AI آپ کے صارفین کو نہیں جانتا؛ آپ جانتے ہیں۔

acceptance criteria آپ کا ٹیسٹ پلان بھی ہیں۔ جب story بن جائے تو ہر criterion کو خود جانچیں۔ لانچ سے پہلے اپنی ایپ کی جانچ کیسے کریں والی گائیڈ اسی پر مبنی ہے۔

user stories دوسری دستاویزات کے ساتھ کہاں فٹ ہوتی ہیں

• ایک product requirements document پوری پروڈکٹ بیان کرتی ہے: مسئلہ، صارفین، دائرہ۔ User stories اس کے اندر کے تفصیلی ٹکڑے ہیں۔ دیکھیں AI سے PRD کیسے لکھیں۔
• ایک bug report کسی ایسی چیز کو بیان کرتی ہے جو ٹوٹ گئی ہے، اس story کے مقابلے میں جو پہلے بن چکی تھی۔ دیکھیں اچھی بگ رپورٹ کیسے لکھیں۔
• ایک MVP سب سے چھوٹا stories کا مجموعہ ہے جو بنیادی قدر دیتا ہے۔ دیکھیں MVP کیا ہے۔

عام غلطیاں

• “بطور صارف…” بہت مبہم۔ صارف کی اصل قسم کا نام لیں۔
• “تاکہ” چھوڑ دینا۔ وجہ کے بغیر آپ معقول سمجھوتے نہیں کر سکتے۔
• ضرورت کے بجائے حل لکھنا۔ “مجھے ڈراپ ڈاؤن چاہیے” کسی کے ڈیزائن کے بارے میں سوچنے سے پہلے ہی اسے طے کر دیتا ہے۔
• ایسے criteria جو جانچے نہ جا سکیں۔ “آسان”، “تیز” اور “بدیہی” خواہشات ہیں، criteria نہیں۔
• وہ stories جو درحقیقت epics ہیں۔ “اپنا اکاؤنٹ منظم کریں” دس stories ہیں۔
• سب stories پہلے سے لکھ دینا۔ اگلی چند کو تفصیل سے لکھیں؛ باقی کو ایک لائن کے طور پر رکھیں یہاں تک کہ آپ ان تک پہنچیں۔

Mythex میں stories

Mythex میں Plan موڈ ایک خیال کو stories میں بدلنے کے لیے اچھی جگہ ہے: ایجنٹ کچھ بدلنے سے پہلے طریقے پر بات کرتا ہے۔ جب کوئی story تیار ہو تو Build پر جائیں اور اسے چسپاں کریں، ہر پیغام میں ایک story۔ ہر ایک کے بعد /test پریویو میں کلک کر کے فلو کی جانچ کر سکتا ہے، اور اگر کوئی جواب غلط سمت میں گیا ہو تو Revert to this point سے اسے واپس کر سکتے ہیں۔ دیکھیں ڈاکس میں مؤثر پرامپٹس، اور ہماری گائیڈ AI ایپ بلڈرز کے لیے پرامپٹس کیسے لکھیں۔

User story چیک لسٹ

• ایک مخصوص قسم کے صارف کا نام لیتی ہے
• ایک ضرورت بیان کرتی ہے، ڈیزائن نہیں
• ایک حقیقی “تاکہ” کی وجہ شامل ہے
• تین سے چھ قابلِ جانچ acceptance criteria ہیں
• کم از کم ایک ایج کیس یا غلطی کا احاطہ کرتی ہے
• بتاتی ہے کہ کیا دائرے سے باہر ہے
• ایک ہی نشست میں بنانے اور جانچنے کے لیے کافی چھوٹی ہے
• بننے کے بعد criteria ایک ایک کر کے جانچے گئے

سوالات