User Story چیست و چگونه باید نوشته شود؟

User Story (داستان کاربری) یک توصیف کوتاه از کارکرد مطلوب است، از زاویهٔ کسی که آن کارکرد را می‌خواهد یا به آن نیاز دارد. هدفش این نیست که کل نیازمندی را در یک جمله زندانی کند؛ هدفش شروع یک گفت‌وگو و ساخت فهم مشترک است تا تیم بداند چه ارزشی باید برسد.

Scrum Guide قالب اجباری User Story تعیین نمی‌کند؛ از Product Backlog items حرف می‌زند. در صنعت، بسیاری از تیم‌های Scrum آیتم‌های بک‌لاگ را به‌صورت User Story می‌نویسند چون گفت‌وگو محور است. این مقاله آن رسم رایج را توضیح می‌دهد و مرزش با تعریف رسمی بک‌لاگ را روشن نگه می‌دارد.

منبع اصلی توضیح عملی این صفحه، راهنمای User Stories در Mountain Goat Software است؛ پیوند با آرتیفکت‌های Scrum از Scrum Guide می‌آید.

پاسخ کوتاه

یک User Story خوب یادآور گفت‌وگوست: چه کسی سود می‌برد، چه می‌خواهد انجام دهد، و چرا. قالب رایج «به‌عنوان … می‌خواهم … تا …» مفید است وقتی گفت‌وگو را بهتر می‌کند — نه وقتی آیین اجباری شود. جزئیات کامل از طریق conversation و confirmation (مثلاً Acceptance Criteria) رشد می‌کند.

داستان را قبل از Sprint تا حدی روشن کنید که تیم باور کند در یک Sprint قابل Done شدن است. داستان خیلی درشت را بشکنید؛ داستان خیلی تجویزی را باز کنید تا فضا برای طراحی بهتر بماند.

قالب رایج و مثال

قالب متداول:

As a [type of user], I [need/want/am required] to [do something], so that [reason or benefit].

مثال از همان راهنما: «به‌عنوان شرکت‌کنندهٔ همایش، باید بتوانم نشست‌ها را بر اساس موضوع فیلتر کنم تا سریع‌تر مرتبط‌ترین‌ها را پیدا کنم.» جمله نقطهٔ شروع است؛ نیازمندی کامل در گفت‌وگوی بعدی شکل می‌گیرد.

نسخهٔ ضعیف معمولاً کاربر، هدف یا دلیل را مبهم می‌گذارد: «به‌عنوان کاربر می‌خواهم گزارش ببینم تا اطلاعات داشته باشم.» نسخهٔ قوی‌تر تصمیم کاربر را نشان می‌دهد: «به‌عنوان مدیر فروش منطقه‌ای، باید درآمد ماهانه را بر اساس قلمرو مقایسه کنم تا بفهمم کجا به مربیگری نیاز است.»

Card، Conversation، Confirmation

Ron Jeffries داستان‌ها را با سه واژه توصیف کرده است که راهنمای Mountain Goat هم برجسته می‌کند:

• Card: یادداشت کوتاه — کارت فیزیکی، استیکر، یا آیتم در ابزار.
• Conversation: جایی که فهم رشد می‌کند؛ اهداف کاربر، بده‌بستان، لبه‌ها، قواعد کسب‌وکار، گزینه‌های طراحی.
• Confirmation: چگونه می‌فهمیم تمام شده — Acceptance Criteria، مثال‌ها، تست‌ها، اسکچ‌ها یا یادداشت‌های روشن‌کننده.

داستان مفید هر سه را دارد. اگر فقط Card بنویسید و Conversation را رد کنید، به مشخصات یتیم می‌رسید. اگر Confirmation نباشد، Demo تبدیل به بحث «منظورم این نبود» می‌شود.

چه چیزی داستان خوب می‌سازد؟

بر اساس همان راهنما، داستان‌های خوب معمولاً چهار کیفیت دارند:

1. ارزش روشن: کسی باید به تمام‌شدنش اهمیت بدهد — کاربر، کسب‌وکار، کاهش ریسک، یا انطباق.
2. به‌اندازهٔ کافی کوچک برای تمام شدن در یک Sprint: داستان درشت توهم پیشرفت می‌سازد.
3. قابل آزمون: تیم بتواند بگوید تمام شده یا نه (جزئیات می‌تواند نزدیک اجرا اضافه شود).
4. فضا برای گفت‌وگو: راه‌حل را بیش از حد زود قفل نکند.

آزمون مفید قبل از ورود به Sprint: آیا تیم می‌فهمد این آیتم را به‌اندازهٔ کافی که باور کند در Sprint تمام می‌شود؟ اگر نه، refinement، مثال، معیار پذیرش یا شکستن لازم است.

چقدر جزئیات؟ و چه کسی می‌نویسد؟

جزئیات باید با فاصله تا اجرا جور باشد. پایین بک‌لاگ می‌تواند درشت و کم‌جزئیات بماند چون اولویت و راه‌حل ممکن است عوض شود. بالای بک‌لاگ نیاز به وضوح بیشتر دارد.

هر کسی می‌تواند داستان بنویسد. در Scrum، Product Owner پاسخگوی Product Backlog است، اما لازم نیست همهٔ جمله‌ها را خودش تایپ کند. توسعه‌دهنده، تستر، طراح، تحلیل‌گر، ذی‌نفع و کاربر همه می‌توانند مشارکت کنند. مهم مشارکت در Conversation است نه مالکیت تایپ اولیه.

Epic

Epic داستان بزرگ است — یادآوری یک قابلیت مهم قبل از دانستن همهٔ جزئیات. وقتی به اجرا نزدیک شد باید به داستان‌های کوچک‌تر قابل اتمام شکسته شود. برچسب Epic را آیینی نکنید؛ اندازه و نزدیکی به Done مهم است.

شکستن داستان و اشتباه تبدیل به تسک فنی

هدف شکستن، ساختن تیکت بیشتر نیست؛ تمام‌کردن کار و گرفتن بازخورد است. اشتباه رایج: شکستن فقط بر اساس لایهٔ فنی («اول API، بعد UI، بعد تست») طوری که تا پایان Sprint هیچ ارزش کاربرقابل‌مشاهده‌ای نرسد.

تفاوت داستان و تسک: داستان پیامد مفید از زاویهٔ ذی‌نفع ارزش است؛ تسک کاری است که تیم برای رساندن آن انجام می‌دهد. «ذخیره روش پرداخت برای تسویهٔ سریع‌تر» داستان است؛ «ساخت جدول توکن پرداخت» معمولاً تسک است.

پیوند با Scrum و Product Backlog

در Scrum، هر شکل از آیتم بک‌لاگ باید به شفافیت کمک کند و در نهایت به Increment مطابق Definition of Done برسد. User Story یک قالب رایج برای همان آیتم‌هاست. PO همچنان پاسخگوی ترتیب و ارتباط روشن است؛ Developers اندازه را تعیین می‌کنند؛ refinement جزئیات را نزدیک اجرا اضافه می‌کند.

اجبار همه چیز به قالب User Story لازم نیست. کار فنی خالص گاهی بهتر به‌صورت technical backlog item، spike یا chore بیان شود — اگر گفت‌وگوی بهتری بسازد. راهنمای Mountain Goat هم می‌گوید فرم کمتر از کیفیت Conversation اهمیت دارد.

اشتباه‌های رایج

• در نظر گرفتن جملهٔ نوشته‌شده به‌عنوان کل نیازمندی.
• داستان‌های خیلی بزرگ که تا پایان Sprint «تقریباً تمام» می‌مانند.
• شکستن به تسک‌های لایه‌ای به‌جای برش‌های ارزشمند.
• نوشتن همه چیز از زاویهٔ Product Owner به‌جای کاربر واقعی.
• افزودن جزئیات بیش از حد خیلی زود و کشتن فضای طراحی.
• اجبار قالب وقتی فرمت دیگر واضح‌تر است.

چک‌لیست قبل از آوردن داستان به Sprint

1. چه کسی سود می‌برد؟
2. چه پیامد، قابلیت یا رفتاری پشتیبانی می‌شود؟
3. چرا الان مهم است؟
4. آیا به‌اندازهٔ کافی کوچک است که در Sprint تمام شود؟
5. آیا فقط بر اساس لایهٔ فنی شکسته نشده؟
6. آیا فضا برای گفت‌وگو و طراحی بهتر مانده؟
7. آیا تیم می‌فهمد برای تمام‌شدن چه چیزهایی باید درست باشد؟ (پیوند به ۰۶۴)

جمع‌بندی برای تصمیم

User Story ابزار همکاری است نه جایگزین تفکر محصول. با Card شروع کنید، با Conversation عمق بدهید، با Confirmation تمام‌شدن را قابل قضاوت کنید. در بستر Scrum، داستان‌ها فقط یکی از شکل‌های مفید Product Backlog item هستند — مفید وقتی شفافیت و ارزش را بالا ببرند، مضر وقتی به مشخصات پنهان یا آیین قالب تبدیل شوند.

تمرین این هفته: یک آیتم مبهم بک‌لاگ را با قالب who/what/why بازنویسی کنید، دو سؤال باز برای Conversation بنویسید، و سه معیار تأیید اولیه پیش‌نویس کنید.

کارگاه نوشتن داستان — نسخهٔ کوتاه

یک کارگاه ۶۰ تا ۹۰ دقیقه‌ای با PO، یک یا دو Developer، و در صورت امکان طراح یا تستر:

1. یک جریان کاربر یا هدف محصول را روی میز بگذارید.
2. ۱۰ دقیقه طوفان کارت‌های who/what/why بدون سانسور.
3. ۲۰ دقیقه ادغام تکراری‌ها و حذف کار بی‌ارزش.
4. ۲۰ دقیقه انتخاب ۳ تا ۵ داستان نزدیک و افزودن سؤال‌های باز.
5. ۱۵ دقیقه پیش‌نویس Confirmation برای همان‌ها.

خروجی باید بک‌لاگ بهتر باشد نه اسلاید زیبا. اگر کارگاه فقط به قالب‌پرانی تبدیل شد، Conversation را عمداً طولانی‌تر کنید.

داستان‌های فنی و ریسک

گاهی کار ضروری کاربر مستقیم ندارد: ارتقای پایگاه‌داده، حذف Secret از مخزن، یا آزمایش فنی (spike). می‌توانید ارزش را از زاویهٔ ریسک عملیاتی یا توانمندسازی قابلیت بعدی بنویسید؛ اگر مصنوعی شد، همان را technical item بنامید و در بک‌لاگ شفاف نگه دارید. پنهان کردن کار فنی ضروری داخل داستان‌های جعلی کاربر، Transparency را کم می‌کند.

داستان و تخمین

تخمین (نقطه، تی‌شرت، یا روز ایده‌آل) ابزار گفت‌وگو دربارهٔ اندازه و عدم‌قطعیت است نه هدف فی‌نفسه. Guide روش تخمین اجباری ندارد. اگر تخمین باعث جنگ اعداد بدون بهبود شکستن داستان می‌شود، اول داستان را کوچک و قابل آزمون کنید؛ بعد در صورت نیاز اندازه بدهید.

نشانهٔ سالم: بعد از نوشتن داستان و AC، تیم می‌گوید «این در Sprint جا می‌شود» یا «باید بشکند». نشانهٔ ناسالم: ساعت‌ها بحث عدد بدون تغییر فهم دامنه.

مثال بازنویسی از ضعیف به قابل Sprint

ضعیف: «به‌عنوان PO داشبورد می‌خواهم تا متریک ببینم.» مشکلات: کاربر واقعی مبهم است، تصمیم نامشخص است، دامنه بی‌کران است.

بهتر: «به‌عنوان PO می‌خواهم ببینم کدام قابلیت‌های منتشرشدهٔ ۳۰ روز اخیر کمترین استفاده را دارند تا تصمیم بگیرم بهبود، ترویج یا حذف کدام است.» حالا تیم می‌تواند دربارهٔ منبع داده، تعریف استفاده، و حداقل UI گفت‌وگو کند — و شاید بفهمد داشبورد کامل لازم نیست و یک ایمیل هفتگی کافی است.

قابل Sprint: همان هدف، شکسته به «نمایش شمار استفاده برای ۵ قابلیت آخر» با AC مشخص؛ فازهای بعدی جدا. این الگوی شکستن ارزش را زود به Review می‌رساند.

داستان در تیم دورکار

Conversation چهره‌به‌چهره در اصول Agile ترجیح داده شده، اما تیم‌های توزیع‌شده می‌توانند همان روح را با تماس کوتاه، سند مشترک، و مثالهای پذیرش حفظ کنند. خطر دورکاری این است که Card در ابزار تنها بماند و Confirmation بعد از کدنویسی نوشته شود. قانون ساده: هیچ داستانی بدون یک گفت‌وگوی همزمان (حتی ۱۵ دقیقه) وارد Sprint نشود مگر اینکه قبلاً با همان تیم refine شده باشد.

داستان، نقشهٔ داستان و انتشار

Story mapping (که در راهنمای Mountain Goat هم به‌عنوان عمل مکمل آمده) کمک می‌کند داستان‌ها را در سفر کاربر ببینید نه در لیست تخت. وقتی نقشه دارید، برش انتشار واضح‌تر می‌شود: حداقل مسیر برای یک نتیجهٔ کاربر، بعد لایه‌های بعدی. بک‌لاگ تخت بدون نقشه اغلب پر از قابلیت‌های موازی می‌شود که هیچ‌کدام به‌تنهایی ارزش کامل نمی‌رسانند.

برای MVP، از نقشه یک برش افقی نازک انتخاب کنید که از ابتدا تا انتهای یک سفر حیاتی را Done کند — حتی اگر هر قدم ساده باشد — به‌جای عمیق کردن یک قدم و رها کردن بقیه.

زبان فارسی و اصطلاح انگلیسی

در تیم‌های فارسی‌زبان، نوشتن داستان به فارسی با نگه داشتن اصطلاحات User Story، AC و Done معمولاً بهترین تعادل است. قالب را ترجمه کنید («به‌عنوان … می‌خواهم … تا …») ولی واژه‌های مشترک صنعت را عوض نکنید تا با ابزار و منابع انگلیسی جدا نشوید. مهم‌تر از زبان، وضوح who/what/why است.

از داستان‌هایی که فقط ترجمهٔ تسک فنی‌اند خودداری کنید: «به‌عنوان سیستم می‌خواهم ایندکس بسازم» معمولاً Conversation مفیدی نمی‌سازد مگر ارزش عملیاتی یا کاربر پشتش آشکار شود.

منابع و مراجع

• Mountain Goat Software — User Stories: What They Are, How to Write Them, and Examples — https://www.mountaingoatsoftware.com/agile/user-stories
• The 2020 Scrum Guide™ — Product Backlog items and refinement — https://scrumguides.org/scrum-guide.html