یکی از پرتکرارترین اشتباههای تیمهای اسکرام، یکیدانستن دو بکلاگ مختلف است: یکی فهرست بزرگ و همیشهدرحالتغییر محصول، و دیگری فهرست کوچک و ثابت یک اسپرینت. وقتی این دو قاطی شوند، تیم وسط اسپرینت نمیداند واقعاً باید روی چه چیزی متمرکز باشد، صاحب محصول فهرست اجرایی تیم را دستکاری میکند و در پایانِ اسپرینت هم نه نتیجهای روشن وجود دارد و نه مبنایی برای برنامهریزی اسپرینت بعد.
اگر تازه با اسکرام آشنا شدهاید یا میخواهید اسپرینتهایتان را دقیقتر ببندید، این مقاله همهچیز را پوشش میدهد: تعریف دقیق Sprint Backlog، تفاوتش با Product Backlog، روش ساخت گامبهگام، تعیین ظرفیت با Velocity، هدف اسپرینت و اشتباههایی که این فهرست کوچک را خراب میکنند.
Sprint Backlog چیست؟ (پاسخ سریع)
Sprint Backlog مجموعهای از آیتمهای بکلاگ محصول (بههمراه برنامهٔ انجامشان و معمولاً تسکهای شکستهشده) است که تیم در جلسهٔ برنامهریزی اسپرینت برای همان اسپرینت انتخاب کرده و متعهد به تحویل آنهاست. این فهرست کوچک و متمرکز است، برخلاف Product Backlog که فهرست زنده و همیشهدرحالتغییر کل محصول است.
Sprint Backlog دقیقاً شامل چه چیزهایی است؟
یک Sprint Backlog خوب، فقط «لیست آیتم» نیست؛ از سه جزء تشکیل میشود:
- آیتمهای انتخابشده: همان آیتمهایی از Product Backlog که تیم برای این اسپرینت برداشته است.
- تسکهای شکستهشده: هر آیتم به کارهای اجرایی کوچک تقسیم میشود تا پیشرفت روزانه قابلردیابی باشد.
- هدف اسپرینت: جملهای که نتیجهٔ کلیدی اسپرینت را روشن میکند.
مثال عددی: فرض کنید تیم یک آیتم «ورود با شماره موبایل» را انتخاب کرده. این آیتم به چهار تسک شکسته میشود: طراحی فرم ورود، ساخت API احراز هویت، ارسال کد تأیید پیامکی و نوشتن تست. حالا هر روز در Daily Standup، تیم دقیقاً میداند کدام تسک در چه وضعیتی است — نه اینکه فقط یک آیتم مبهم به اسم «ورود با موبایل» داشته باشد.
همین امروز به دوایتیفای بپیوندید
پروژهها را بدون سردرگمی پیش ببرید: همهٔ وظایف، پیشرفتها و گزارشهای تیم در یک محیط یکپارچه. ساختهشده برای شرکتها، استارتاپها و تیمهای دورکار — با راهاندازی چنددقیقهای، پشتیبانی فارسی و نسخهٔ آزمایشی رایگان.
فرق Sprint Backlog و Product Backlog چیست؟
این دو بکلاگ نقشهای کاملاً متفاوتی دارند و خلط آنها ریشهٔ بیشتر مشکلات است:
| معیار | Product Backlog | Sprint Backlog |
|---|---|---|
| دامنه | همهٔ کارهای ممکن محصول | کارهای یک اسپرینت مشخص |
| مالکیت | صاحب محصول (Product Owner) | تیم توسعه |
| تغییر | همیشه در حال تغییر و اولویتبندی | در طول اسپرینت تقریباً ثابت |
| اندازه | بزرگ، باز و بیپایان | کوچک، محدود و قابلتکمیل |
| هدف | چشمانداز بلندمدت محصول | تحویل هدف اسپرینت |
| افق زمانی | بدون مهلت مشخص | فقط طول همان اسپرینت |
نکتهٔ کلیدی: Product Backlog «چیزهایی که روزی باید بسازیم» را نگه میدارد؛ Sprint Backlog «چیزهایی که همین دو هفته میسازیم» را. هر آیتمی وارد Sprint Backlog شود، یک تعهد واقعی است، نه یک آرزو.
چطور Sprint Backlog ساخته میشود؟ (گامبهگام)
ساخت Sprint Backlog در جلسهٔ برنامهریزی اسپرینت (Sprint Planning) انجام میشود و پنج گام دارد:
- صاحب محصول، آیتمهای بالای Product Backlog را معرفی میکند و هدف پیشنهادی اسپرینت را توضیح میدهد.
- تیم ظرفیت واقعی خودش را میسنجد — معمولاً بر اساس Velocity میانگین چند اسپرینت گذشته.
- تیم بهاندازهٔ ظرفیت، آیتم انتخاب میکند و دربارهٔ هر آیتم سؤال میپرسد تا ابهام نداشته باشد.
- آیتمها به تسکهای اجرایی شکسته میشوند و مسئول و تخمین هر تسک مشخص میشود.
- هدف اسپرینت بهصورت روشن نوشته میشود تا همه بدانند «چرا» این کارها را انجام میدهند.
مثال عددی: تیم ۵ نفرهای Velocity میانگین ۲۰ امتیاز دارد. در برنامهریزی، صاحب محصول آیتمهای بالای لیست را معرفی میکند. تیم بهجای برداشتن ۳۰ امتیاز کار (که به اسپرینت ناتمام میانجامد)، آیتمهایی به مجموع ۱۸ تا ۲۰ امتیاز انتخاب میکند. نتیجه: اسپرینتی واقعبینانه که شانس تمامشدنش بالاست.
ظرفیت اسپرینت چطور تعیین میشود؟
یکی از رایجترین علتهای اسپرینت ناتمام، انتخاب کار بیشتر از ظرفیت است. برای تعیین ظرفیت، این موارد را در نظر بگیرید:
- Velocity چند اسپرینت گذشته: اگر تیم در چهار اسپرینت اخیر ۱۵، ۱۷، ۱۶ و ۱۸ امتیاز تمام کرده، ظرفیت واقعی تقریباً ۱۶ تا ۱۷ امتیاز است.
- مرخصی و غیبت اعضا: اگر یکی از اعضای کلیدی این اسپرینت ۳ روز مرخصی دارد، باید ظرفیت را پایینتر ببندید.
- کارهای جانبی: نگهداری، پشتیبانی و باگهای ورودی هم بخشی از وقت واقعی تیماند و باید لحاظ شوند.
نکته مهم: ظرفیت را بر اساس دادهٔ واقعی ببندید، نه آرزو. انتخاب ۲۵ امتیاز وقتی Velocity واقعی ۱۶ است، یعنی اسپرینتی که از ابتدا محکوم به ناتمام ماندن است.
هدف اسپرینت چیست و چرا مهم است؟
علاوه بر فهرست آیتمها، هر اسپرینت یک «هدف» دارد که در یک جمله خلاصه میشود؛ مثلاً: «کاربر بتواند با شماره موبایل وارد شود و حسابش را بازیابی کند». هدف اسپرینت سه کار میکند:
- قطبنمای تصمیمهاست: وقتی وسط کار اولویتها مبهم میشود، تیم به هدف برمیگردد.
- معیار موفقیت است: اسپرینت وقتی موفق است که هدف برآورده شود، نه اینکه صرفاً همهٔ تسکها تیک بخورند.
- زبان مشترک با ذینفعان است: در مرور اسپرینت، تیم دربارهٔ «رسیدن به هدف» گزارش میدهد، نه دربارهٔ تعداد تسک.
مثال عددی: فرض کنید هدف اسپرینت «کاهش زمان ثبتنام از ۴ دقیقه به زیر ۲ دقیقه» باشد. تیم ۸ آیتم مرتبط برمیدارد. وسط اسپرینت، اگر درخواست جدیدی بیاید که به این هدف ربطی ندارد، تصمیمگیری ساده میشود: آن را به اسپرینت بعد میاندازید.
چرا Sprint Backlog باید در طول اسپرینت ثابت بماند؟
اگر وسط اسپرینت مدام کار اضافه یا کم شود، تمرکز تیم از بین میرود و هدف اسپرینت فراموش میشود. ثبات به تیم اجازه میدهد بدون حواسپرتی کار را تا انتها ببرد و در پایان، دادهٔ واقعی برای سنجش Velocity به دست بیاورد.
بااینحال این یک Trade-off است: ثبات بیشازحد هم اشکال دارد. استثنای مهم این است که اگر یک تغییر حیاتی پیش آمد — مثلاً یک باگ بحرانی که مشتریان اصلی را متوقف کرده — صاحب محصول میتواند با توافق تیم، آیتمی را جابهجا کند. این انعطافِ کنترلشده، اسکرام را از برنامهریزی خشک و سنتی جدا میکند.
مزایا و محدودیتهای Sprint Backlog
مزایا:
- تمرکز تیم را روی مجموعهای کوچک و مشخص نگه میدارد.
- تعهد واقعی میسازد، نه فهرست بیپایان.
- پایهٔ محاسبهٔ Velocity و برنامهریزیهای بعدی است.
- با شکستن به تسک، پیشرفت روزانه شفاف میشود.
محدودیتها و Trade-off:
- اگر ظرفیت اشتباه بسته شود، یا اسپرینت ناتمام میماند یا وقت هدر میرود.
- ثبات آن باعث میشود پاسخگویی به تغییرات فوری، کندتر شود.
- بدون هدف اسپرینت، به یک لیست بیربط تبدیل میشود.
- برای کارهای عملیاتیِ پیوسته (مثل پشتیبانی) که «پایان» مشخصی ندارند، قالب اسپرینت چندان طبیعی نیست و بهتر است با روشهای جریانمحور مثل کانبان ترکیب شود.
اشتباهات رایج
- پرکردن بیشازظرفیت: انتخاب آیتم بیشتر از Velocity واقعی، یعنی اسپرینت ناتمام و تیم ناامید.
- تغییر مداوم وسط اسپرینت: تمرکز تیم را از بین میبرد و دادهٔ Velocity را خراب میکند.
- نبود هدف اسپرینت: بدون هدف، بکلاگ فقط فهرستی بیربط از کارهاست.
- خلط مالکیت با Product Backlog: وقتی صاحب محصول Sprint Backlog را هم مدیریت کند، تیم مالکیت تعهدش را از دست میدهد.
- آیتمهای مبهم: آیتمی که معیار پذیرشش روشن نیست، وسط اسپرینت به مشکل میخورد.
نکات کاربردی
- نکته مهم: Sprint Backlog را بر اساس Velocity واقعی تیم انتخاب کنید، نه آرزوها.
- ترفند کاربردی: هر آیتم را به تسکهای کوچک (کمتر از یک روز کار) بشکنید تا پیشرفت روزانه قابلردیابی باشد.
- اشتباه رایج: انتخاب آیتمهای مبهم؛ قبل از اسپرینت، معیار پذیرش (Acceptance Criteria) را برای هر آیتم روشن کنید.
- قبل از شروع این را بدانید: Sprint Backlog باید در ابزار مدیریت اسپرینت ثبت شود تا تیم هر روز وضعیتش را ببیند و در پایان، امتیاز کارهای تمامشده بهدرستی جمع شود.
دوایتفای و مدیریت Sprint Backlog
برای اجرای درست اسپرینت، به ابزاری نیاز دارید که Sprint Backlog را از Product Backlog جدا نگه دارد و پیشرفت را نشان دهد. در دوایتفای میتوانید بکلاگ محصول و اسپرینتها را جدا تعریف کنید، آیتمها را با تخمین (Story Point) به اسپرینت منتقل کنید، هر آیتم را به تسک و زیرتسک بشکنید، مسئول و مهلت بگذارید و پیشرفت را در برد کانبان و نمودارها دنبال کنید. به این ترتیب، ظرفیتسنجی و محاسبهٔ Velocity بر پایهٔ دادهٔ واقعی انجام میشود و تمرکز تیم روی هدف اسپرینت حفظ میماند.
سوالات متداول
جمعبندی
Sprint Backlog فهرست متمرکز کارهای یک اسپرینت است که از Product Backlog انتخاب میشود و در طول اسپرینت تقریباً ثابت میماند تا تمرکز تیم حفظ شود. آن را بر اساس ظرفیت واقعی (Velocity) ببندید، آیتمها را به تسک بشکنید، هدف اسپرینت را روشن کنید و کل جریان را در ابزار مدیریت اسپرینت دنبال کنید. با همین نظم ساده، از یک فهرست شلوغ به یک تعهد روشن و قابلاندازهگیری میرسید.
اگر موضوع Sprint Backlog برایتان مفید بود، پیشنهاد میکنیم مدیریت ریسک چیست؟ و چگونه برنامه ریزی درسی کنیم؟ را هم بخوانید.
همین امروز به دوایتیفای بپیوندید
پروژهها را بدون سردرگمی پیش ببرید: همهٔ وظایف، پیشرفتها و گزارشهای تیم در یک محیط یکپارچه. ساختهشده برای شرکتها، استارتاپها و تیمهای دورکار — با راهاندازی چنددقیقهای، پشتیبانی فارسی و نسخهٔ آزمایشی رایگان.
