Sprint Backlog | بک‌لاگ اسپرینت

بک‌لاگ اسپرینت مجموعهٔ آیتم‌های بک‌لاگ محصول است که تیم برای اسپرینت جاری انتخاب و به آن متعهد شده، به‌همراه برنامه‌ای برای تحویل آن‌ها تا هدف اسپرینت محقق شود. مالک و مدیر این مجموعه تیم توسعه است: قرارداد کاری و توافق عملیاتی همان بازهٔ زمانی، نه لیست آرزوی مدیر محصول و نه کل انبار اولویت‌های محصول. وقتی این artifact نباشد یا پراکنده در چت و حافظه بماند، اسپرینت پر از خزش محدوده، کار فراموش‌شده و بحث «مگر قرار نبود؟» می‌شود. تمرکز این صفحه روی خود مجموعهٔ تعهد و برنامهٔ اسپرینت است؛ آیین برنامه‌ریزی و اجرای کامل اسپرینت موضوع جداگانه‌ای است.

چرا بدون تصویر تعهد، اسپرینت شل می‌شود

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

بک‌لاگ اسپرینت خوب تمرکز را نگه می‌دارد چون تعهد مرئی از ورود کار وسط اسپرینت بدون مذاکره محافظت می‌کند. مالکیت تیم را تقویت می‌کند چون محتوای آن را تیم می‌سازد نه اینکه از بیرون دیکته شود. شفافیت برای ذی‌نفع می‌سازد چون همه می‌بینند داخل بازه چه هست. پیش‌بینی‌پذیری و اعتماد وقتی بالا می‌رود که آنچه روی بورد است با آنچه در مرور نشان داده می‌شود یکی بماند. استرس کمتر می‌شود چون مرز ظرفیت جلوی پر کردن بی‌پایان را می‌گیرد.

تعریف عملی: آیتم‌ها به اضافهٔ برنامه

فقط چسباندن چند استوری به ستون «این اسپرینت» کافی نیست. بک‌لاگ اسپرینت شامل همان آیتم‌های انتخاب‌شده به‌علاوهٔ فهم مشترک از نحوهٔ انجام کار است: تجزیه به تسک‌های مشخص، وابستگی‌ها، و گاهی کارهای صریح کاهش ریسک. هدف اسپرینت قطب‌نماست؛ بک‌لاگ اسپرینت مجموعهٔ کارهایی است که تیم باور دارد برای رسیدن به آن هدف در ظرفیت واقعی می‌گنجد. اگر هدف عوض شود بدون بازنگری این مجموعه، artifact دروغین می‌شود.

تفاوت با بک‌لاگ محصول روشن است: بک‌لاگ محصول کل کارهای مرتب‌شدهٔ محصول در افق بلندتر است و معمولاً مالک محصول ترتیب آن را نگه می‌دارد. بک‌لاگ اسپرینت برش متعهد همان افق کوتاه است و تیم توسعه آن را در طول اسپرینت زنده نگه می‌دارد. قاطی کردن این دو باعث می‌شود یا اسپرینت مثل سطل بی‌ته شود یا بک‌لاگ محصول به لیست دو هفته‌ای تقلیل یابد.

ساخت در برنامه‌ریزی، زندگی در هر روز

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

در طول اسپرینت بک‌لاگ اسپرینت زنده است: با یادگیری پیاده‌سازی تسک‌ها تنظیم می‌شوند، اما افزودن کار جدید بدون حذف یا مذاکرهٔ معادل، تعهد را بی‌معنا می‌کند. به‌روزرسانی روزانه همان چیزی است که بورد را از پوستر تشریفاتی به ابزار هماهنگی تبدیل می‌کند.

مالکیت تیم و محافظت از خزش محدوده

مالک محصول اولویت ورودی را می‌آورد؛ تیم تعیین می‌کند چه حجمی را متعهد می‌شود. اگر مالک محصول بک‌لاگ اسپرینت را هر روز مثل wish list ویرایش کند، مالکیت از بین رفته است. سیاست روشن برای تغییر وسط اسپرینت لازم است: کار فوری واقعی با trade-off وارد می‌شود، نه با سکوت و اضافه شدن به انتهای ستون. تیم‌هایی که پشت بک‌لاگ اسپرینت پنهان می‌شوند و هیچ انعطافی نشان نمی‌دهند هم افراط مخالف‌اند؛ ظرفیت نباید صددرصد پر شود تا جای واکنش به مانع واقعی بماند.

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

شفافیت، وابستگی و هماهنگی چندتیمی

ذی‌نفع باید بتواند بدون پرسیدن از پنج نفر ببیند چه چیزی داخل اسپرینت است و پیشرفت تقریبی چیست. وابستگی بین تیم‌ها اگر فقط در ذهن باشد، در روز یکپارچه‌سازی منفجر می‌شود؛ بصری کردن وابستگی بین بک‌لاگ‌های اسپرینت تیم‌های مختلف از غافلگیری integration کم می‌کند. تحلیل الگوی تغییر بک‌لاگ اسپرینت — چه چیزهایی وسط بازه اضافه یا حذف می‌شوند — به بهبود برنامه‌ریزی بعدی کمک می‌کند تا آشوب عادی‌سازی نشود.

ظرفیت، ریسک و کارهای طراحی

اندازه‌گذاری بر اساس ظرفیت واقعی جلسات، مرخصی و آنکال صادقانه‌تر از چسباندن امتیاز ایده‌آل است. کارهای کاهش ریسک را صریح در مجموعه بگذارید نه اینکه «امیدواریم مشکلی پیش نیاید». کار طراحی و پژوهش اگر برای هدف اسپرینت لازم است باید به‌صورت آیتم مرئی با معیار پذیرش باشد، نه کار جانبی نامرئی کنار مهندسی. اسلایس عمودی که تا اینکریمنت قابل‌نمایش می‌رسد بهتر از لایهٔ فقط UI بدون اتصال به ارزش است.

نشانه‌های سلامت و بیماری artifact

سلامت: هدف یک‌جمله‌ای روی بورد، آیتم‌های مرتبط با هدف، تسک‌های به‌روز، کاهش واقعی کار باقی‌مانده، و مرور بدون غافلگیری بزرگ از قلم‌افتاده‌ها. بیماری: ستون اسپرینت به‌عنوان پارکینگ هر ایده، تعهد بدون آمادگی طراحی، carry-over تکراری بدون یادگیری در بازنگری، و پنهان کردن وضعیت واقعی برای «زیبا ماندن» بورد.

نمونه‌های ملموس

هدف: مهمان بتواند بدون حساب کامل خرید را تمام کند. بک‌لاگ اسپرینت: چهار استوری مرتبط با مهمان، پرداخت، و پیام خطا، به‌همراه تسک‌های طراحی کپی و تست. مثال بد: پانزده استوری بی‌ارتباط که فقط برای پر کردن امتیاز جمع شده‌اند. در پشتیبانی داخلی، بک‌لاگ اسپرینت ممکن است شامل رفع باگ بحرانی گزارش‌شده به‌اضافهٔ یک بهبود کوچک فلو باشد — باز هم مجموعهٔ متعهد است نه کل بک‌لاگ محصول.

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

یکی گرفتن با بک‌لاگ محصول. دیکتهٔ محتوا بدون خرید تیم. افزودن وسط اسپرینت بدون trade-off. تجزیه نکردن تا روز آخر. پر کردن ۱۲۰٪ ظرفیت. استفاده از مجموعه به‌عنوان بهانه برای رد هر تغییر مشروع. و انتظار داشتن که صرف وجود لیست، جای برنامه‌ریزی و اجرای منضبط اسپرینت را بگیرد.

جمع‌بندی

بک‌لاگ اسپرینت برش متعهد کار به‌همراه برنامهٔ تحویل در timebox است، متعلق به تیم توسعه، مرئی، زنده‌به‌روز، و محافظت‌شده در برابر خزش بی‌مذاکره. آن را با کل بک‌لاگ محصول و با خود آیین برنامه‌ریزی‌واجرا یکی نگیرید. وقتی این مجموعه صادق باشد، تمرکز، شفافیت و شانس تکمیل تعهد بالا می‌رود؛ وقتی دروغین باشد، اسکرام فقط تئاتر دو هفته‌ای می‌شود.