یکی از اولین سردرگمیهای تیمهای تازهوارد به Agile، تشخیص Epic از Story و Task است. نتیجهٔ این سردرگمی، بکلاگی پر از آیتمهایی است که هم خیلی بزرگاند و هم خیلی کوچک، و هیچکس نمیداند کدام را اول انجام دهد و پیشرفت واقعی چقدر است.
این مشکل فقط زبانی نیست؛ به برنامهریزی، تخمین و حتی اعتماد ذینفعان هم سرایت میکند. وقتی یک «Epic» را بهاشتباه بهعنوان یک کار تکاسپرینتی در اسپرینت میگذارید، اسپرینت ناتمام میماند؛ و وقتی یک Story بزرگ را نمیشکنید، هیچکس نمیتواند بگوید «چقدر دیگر تا تمامشدن مانده».
در این مقاله میبینید Epic در Agile چیست، چه فرقی با Story و Task دارد، سلسلهمراتب درست چطور است، چطور یک Epic را درست بشکنید و چه اشتباههایی این ساختار را خراب میکند.
Epic چیست؟ (پاسخ سریع)
Epic در Agile یک بدنهٔ بزرگ از کار است که برای انجام آن به چند داستان کاربر (User Story) کوچکتر شکسته میشود. Epic معمولاً یک قابلیت یا هدف کلی محصول را نمایندگی میکند و ممکن است چند اسپرینت طول بکشد.
Epic در چارچوب Agile چه جایگاهی دارد؟
نکتهٔ مهم: Epic یک اصطلاح رسمی در راهنمای Scrum نیست، بلکه یک شیوهٔ رایج برای سازماندهی بکلاگ محصول در تیمهای چابک است. Scrum فقط از «Product Backlog» صحبت میکند؛ این که بکلاگ را با Epic، Story و Task ساختاردهی کنید، یک عرف عملی است که خیلی از تیمها برای مدیریت کارهای بزرگ به کار میبرند.
این تمایز کمک میکند Epic را نه یک «قاعدهٔ اجباری»، بلکه ابزاری برای سازماندهی ببینید؛ اگر پروژهتان کوچک است، شاید اصلاً به Epic نیاز نداشته باشید.
همین امروز به دوایتیفای بپیوندید
پروژهها را بدون سردرگمی پیش ببرید: همهٔ وظایف، پیشرفتها و گزارشهای تیم در یک محیط یکپارچه. ساختهشده برای شرکتها، استارتاپها و تیمهای دورکار — با راهاندازی چنددقیقهای، پشتیبانی فارسی و نسخهٔ آزمایشی رایگان.
سلسلهمراتب Epic، Story و Task
| سطح | تعریف | اندازه | مثال |
|---|---|---|---|
| Epic | تم یا هدف بزرگ | چند اسپرینت | «سیستم پرداخت آنلاین» |
| User Story | یک نیاز مشخص کاربر | یک اسپرینت یا کمتر | «کاربر میتواند با کارت پرداخت کند» |
| Task | واحد اجرایی کوچک | چند ساعت تا چند روز | «طراحی صفحهٔ ورود کارت» |
قانون ساده: Epic بزرگ است، به چند Story میشکند و هر Story به چند Task تقسیم میشود.
Epic در برابر Feature
گاهی یک سطح میانی به نام Feature هم به کار میرود. برای روشنشدن:
- Epic: یک هدف بزرگ و کلی؛ مثلاً «بهبود تجربهٔ پرداخت».
- Feature: یک قابلیت مشخص ذیل Epic؛ مثلاً «پرداخت با کیف پول».
- User Story: یک نیاز واحد از دید کاربر؛ مثلاً «کاربر بتواند از کیف پول شارژ کند».
همهٔ تیمها از چهار سطح استفاده نمیکنند؛ بسیاری با همان سه سطح Epic ← Story ← Task راحتاند. نکتهٔ تصمیمگیری: فقط وقتی Feature اضافه کنید که Epic واقعاً آنقدر بزرگ باشد که یک سطح میانی، مدیریت و گزارشگیری را سادهتر کند؛ وگرنه سربار اضافه است.
چطور یک Epic خوب بنویسیم؟
یک Epic بدون هدف روشن، فقط یک عنوان بزرگ است. ساختار پیشنهادی برای تعریف Epic:
- هدف را در یک جمله بنویسید: این Epic قرار است چه ارزشی برای کاربر یا کسبوکار بسازد؟
- محدوده را روشن کنید: چه چیزهایی داخل Epic است و چه چیزهایی نیست.
- معیار موفقیت بگذارید: از کجا بفهمیم Epic واقعاً تمام شده؟
- به داستانهای کاربر بشکنید: هر بخش قابلتحویل را به یک Story تبدیل کنید.
یک مثال کامل از شکستن Epic
Epic: «افزودن سیستم نظرات به وبلاگ»
این Epic به این داستانهای کاربر میشکند:
- بهعنوان خواننده، میخواهم برای یک مقاله نظر بگذارم، تا نظرم را بیان کنم.
- بهعنوان نویسنده، میخواهم نظرات را تأیید کنم، تا از اسپم جلوگیری کنم.
- بهعنوان خواننده، میخواهم به نظر دیگران پاسخ دهم، تا گفتگو شکل بگیرد.
و هر داستان، به تسکهای اجرایی میشکند؛ مثلاً داستان اول به: طراحی فرم نظر، ساخت API ذخیره، و نمایش نظرات.
مثال عددی: تخمین در طول سلسلهمراتب
فرض کنید Epic «افزودن سیستم نظرات» در مجموع ۳۰ Story Point تخمین زده میشود و تیم در هر اسپرینت حدود ۱۰ Story Point تحویل میدهد. پس این Epic حدود ۳ اسپرینت طول میکشد. با شکستنش به داستانها، میتوانید در اسپرینت اول فقط داستان «گذاشتن نظر» (۸ امتیاز) را تحویل بدهید و بقیه را به اسپرینتهای بعد موکول کنید. نتیجه: بهجای انتظار سه اسپرینت برای کل Epic، از پایان اسپرینت اول بخشی از ارزش به دست کاربر میرسد.
مثال عددی دوم: اثر شکستن بر پیشبینی زمان
تیمی روی Epic «راهاندازی داشبورد گزارشگیری» کار میکند که ۴۰ امتیاز تخمین زده شده و Velocity تیم هم ۲۰ امتیاز در اسپرینت است. بدون شکستن، همهٔ ارزش بعد از ۲ اسپرینت میرسد. اما اگر Epic به دو بخش «گزارش سادهٔ فروش» (۱۵ امتیاز) و «داشبورد کامل با فیلتر» (۲۵ امتیاز) شکسته شود، بخش اول در کمتر از یک اسپرینت قابل تحویل است و مدیر فروش میتواند زودتر از گزارش ساده استفاده کند.
چرا باید Epic را بشکنیم؟
- قابل مدیریت بودن: کار بزرگ و مبهم، قابل تخمین و برنامهریزی نیست.
- تحویل افزایشی: با شکستن، ارزش بهصورت تدریجی تحویل داده میشود.
- اولویتبندی بهتر: میتوانید فقط بخشهای پراهمیت Epic را زودتر انجام دهید.
- شفافیت پیشرفت: پیشرفت واقعی با داستانهای کوچک قابل اندازهگیری است.
- کاهش ریسک: کار کوچک، ریسک کمتری برای شکست و دوبارهکاری دارد.
چه زمانی یک Story باید شکسته شود؟
یک داستان کاربر وقتی خیلی بزرگ است که:
- در یک اسپرینت تمام نمیشود.
- تخمین آن از حد معمول (مثلاً بالاترین Story Point تیم) بیشتر است.
- چند کار مستقل و بیربط را با هم دارد.
در این صورت، داستان را به چند داستان کوچکتر یا به تسک بشکنید. قانون طلایی: هر Story باید بهتنهایی قابل تحویل و ارائه به کاربر باشد، حتی اگر بخش کوچکی از یک قابلیت بزرگتر است.
مزایا و Trade-off سلسلهمراتب بکلاگ
مزایا:
- دید کلی و جزئیات را همزمان فراهم میکند.
- برنامهریزی و گزارش پیشرفت را ساده میکند.
- ارتباط کار روزانه با اهداف بزرگتر را روشن نگه میدارد.
Trade-off و محدودیتها:
- سطوح زیاد میتواند پیچیدگی و سربار اداری اضافه کند.
- شکستن بیشازحد، کار را به ریزهکاریهای غیرقابلمدیریت تبدیل میکند.
- اگر تیم کوچک و کار ساده است، سه سطح ممکن است زیادهروی باشد.
اشتباهات رایج
- خلط Epic با Story: یک کار یکاسپرینتی را Epic صدا زدن، بکلاگ را شلوغ میکند.
- شکستن بیشازحد: Epic را به تسکهای ریز و غیرقابلمدیریت خرد کردن.
- نداشتن سلسلهمراتب: بکلاگی که همهٔ آیتمها در یک سطحاند.
- فراموشکردن چرایی: Epic بدون هدف روشن، فقط یک عنوان بزرگ است.
- نگهداشتن Epicهای کهنه: Epicهای نیمهکاره که مدتها در بکلاگ میمانند بدون مرور.
- گذاشتن Epic در اسپرینت: Epic خودش به اسپرینت نمیرود؛ داستانهای شکستهشدهاش میروند.
جدول: چه زمانی از کدام سطح استفاده کنیم؟
| وضعیت | انتخاب درست |
|---|---|
| کار در یک اسپرینت تمام میشود | Story |
| کار چند اسپرینت طول میکشد | Epic ← چند Story |
| یک فعالیت کوچک و مشخص برای یک نفر | Task |
| قابلیت بزرگ با چند زیرقابلیت مستقل | Epic ← Feature ← Story |
نکات کاربردی
- نکته مهم: قبل از شروع هر Epic، هدفش را در یک جمله بنویسید؛ Epic بدون هدف، پراکنده میشود.
- ترفند کاربردی: اگر Epic بزرگ است، اول بخشی را که بیشترین ارزش را دارد انتخاب و به یک اسپرینت بشکنید.
- ترفند کاربردی دوم: Epic را بهعنوان «برچسب» یا «پروژهٔ والد» نگه دارید تا پیشرفت Story ها زیر آن جمع شود.
- اشتباه رایج: گذاشتن Epic در اسپرینت بهعنوان یک آیتم؛ Epic خودش به اسپرینت نمیرود، داستانهای شکستهشدهاش میروند.
- قبل از شروع این را بدانید: ابزار مدیریت پروژه باید این سلسلهمراتب را بهصورت بومی پشتیبانی کند تا Epic و Story و Task به هم وصل بمانند.
روشهای عملی برای شکستن Epic
شکستن Epic فقط «کوچککردن» نیست؛ باید به کارهای قابل تحویل برسید. چند الگوی رایج برای شکستن:
- شکستن بر اساس جریان کاربر: هر مرحله از مسیر کاربر، یک Story میشود.
- شکستن بر اساس سناریو: هر حالت خاص کاربر، یک Story میشود (موفق، خطا، حالت ویژه).
- شکستن بر اساس قانون ۸۰/۲۰: بخشی که بیشترین ارزش را دارد اول، و بقیه بعداً.
- شکستن بر اساس «نسخهٔ اول ساده»: ابتدا سادهترین نسخهٔ قابل استفاده، بعد افزودن امکانات تکمیلی.
پیشرفت Epic را چطور گزارش کنیم؟
وقتی Epic به چند Story شکسته میشود، پیشرفت آن باید بهصورت تجمیعی دیده شود. سه شاخص معمول:
- درصد تکمیل Story ها: چند داستان از چند داستان تمام شده است.
- امتیاز تحویلشده: مجموع Story Point های تمامشده نسبت به کل امتیاز Epic.
- ارزش تحویلشده: آیا بخشهایی که تمام شدهاند، قابل استفادهٔ واقعیاند؟
نکتهٔ مهم: درصد تکمیل باید بر اساس «تحویل واقعی» باشد، نه «در حال انجام». Epicای که ۵۰٪ داستانهایش «در حال انجام» است، عملاً هنوز چیزی قابل استفاده تحویل نداده است.
آیا Epic باید مهلت و مسئول مشخص داشته باشد؟
Epic خودش معمولاً مسئولِ «مالکیت» دارد — کسی که چرایی و محدودهٔ آن را نگه میدارد — اما اجرا در سطح Story و Task مسئولدار میشود. مهلت هم بهتر است در سطح Story باشد، چون Epic بهخودیخود چنداسپرینتی است و مهلت سفتوسخت برایش میتواند به عجله و کیفیتپایین منجر شود. بهجای مهلت، یک «چشمانداز زمانی» تقریبی کافی است.
Epic با Theme و Initiative چه فرقی دارد؟
در مقیاسهای بزرگ، گاهی اصطلاحهای دیگری هم شنیده میشود که باید جایشان را بدانید:
- Theme: یک گروه موضوعی از چند Epic یا Story مرتبط که الزاماً سلسلهمراتب اجرایی نیست؛ بیشتر برای دستهبندی به کار میرود.
- Initiative: مجموعهای از چند Epic که یک هدف استراتژیک را دنبال میکند؛ یک سطح بالاتر از Epic.
برای بیشتر تیمها همین سه سطح Epic ← Story ← Task کافی است. فقط وقتی بهدنبال همترازی استراتژیک در سازمان بزرگ هستید، لایههای Theme و Initiative معنا پیدا میکنند — وگرنه سربار بیفایدهاند.
نقش صاحب محصول در مدیریت Epic
صاحب محصول مالکِ «چرایی» هر Epic است. وظیفهٔ او در قبال Epic عبارت است از: تعریف هدف و محدوده، اولویتبندی آن نسبت به سایر Epic ها، شکستن به داستانهای کاربر، و تصمیمگیری دربارهٔ ادامه یا توقف آن در مرور دورهای بکلاگ. اگر Epic بیهدف و بیمالک بماند، بهسرعت به یک «شبهپروژهٔ» فراموششده تبدیل میشود که فقط جای بکلاگ را شلوغ میکند.
دوایتفای و مدیریت سلسلهمراتب
مدیریت Epic، Story و Task به ابزاری نیاز دارد که این سلسلهمراتب را واقعاً نگه دارد. در دوایتفای میتوانید اهداف را به پروژه، تسک و زیرتسکهای چندلایه بشکنید و همین ساختار را برای Epic ← Story ← Task به کار ببرید؛ هر سطح مسئول، مهلت و وضعیت خودش را دارد و پیشرفت از زیرتسکها به Epic بهصورت یکپارچه دیده میشود.
سوالات متداول
جمعبندی
Epic یک هدف بزرگ است که به Story و Task میشکند. این سلسلهمراتب، کار بزرگ را قابل مدیریت، قابل تخمین و قابل تحویل افزایشی میکند. Epic را با هدف روشن تعریف کنید، به داستانهای کاربر قابلتحویل بشکنید و در ابزار مدیریت پروژه، این سلسلهمراتب را بهصورت بومی نگه دارید تا پیشرفت از پایین به بالا بهدرستی جمع شود.
اگر موضوع Epic در Agile برایتان مفید بود، پیشنهاد میکنیم راهنمای جامع برنامهریزی هفتگی و انواع برنامه ریزی را هم بخوانید.
همین امروز به دوایتیفای بپیوندید
پروژهها را بدون سردرگمی پیش ببرید: همهٔ وظایف، پیشرفتها و گزارشهای تیم در یک محیط یکپارچه. ساختهشده برای شرکتها، استارتاپها و تیمهای دورکار — با راهاندازی چنددقیقهای، پشتیبانی فارسی و نسخهٔ آزمایشی رایگان.
