Sprint چیست و چگونه باید یک Sprint خوب برنامه‌ریزی شود؟

در Scrum Guide، Sprintها ضربان قلب چارچوب‌اند: جایی که ایده‌ها به ارزش تبدیل می‌شوند. Sprint یک رویداد با طول ثابت حداکثر یک ماه است که بلافاصله بعد از پایان Sprint قبلی، Sprint جدید شروع می‌شود. همهٔ کار لازم برای رسیدن به Product Goal — از جمله Planning، Daily Scrum، Review و Retrospective — داخل Sprintها رخ می‌دهد.

خیلی از تیم‌ها Sprint را فقط «بازهٔ دو هفته برای بستن تیکت» می‌فهمند. آن تعریف ناقص است. Sprint خوب یک هدف واحد (Sprint Goal) دارد، کیفیت را پایین نمی‌آورد، و با بازرسی و تطبیق به Product Goal نزدیک می‌شود — نه فقط با سوزاندن استوری‌پوینت.

این صفحه تعریف و قواعد داخل Sprint را از Guide می‌آورد، بعد Sprint Planning را موضوع‌به‌موضوع شرح می‌دهد، و در پایان چک‌لیست عملی برای تیم‌های کوچک و متوسط می‌گذارد.

پاسخ کوتاه

Sprint یک timebox ثابت (≤ یک ماه) برای ایجاد یک Increment قابل استفاده به سمت Product Goal است. برنامه‌ریزی خوب سه سؤال را جواب می‌دهد: چرا این Sprint ارزشمند است؟ چه چیزی می‌تواند Done شود؟ چگونه کار انتخاب‌شده انجام می‌شود؟ خروجی این سه، با هم Sprint Backlog را می‌سازند: Sprint Goal + آیتم‌های انتخاب‌شده + برنامهٔ انجام.

نشانهٔ Sprint بد: هدف مبهم، تعهد بیش از ظرفیت، کاهش کیفیت برای «تمام کردن»، و Review بدون تصمیم. نشانهٔ Sprint خوب: هدف روشن برای ذی‌نفع، آیتم‌های آماده، Definition of Done زنده، و تطبیق روزانه حول همان هدف.

قواعد داخل Sprint

Guide برای مدت Sprint این‌ها را می‌گوید:

• تغییری که Sprint Goal را به خطر بیندازد اعمال نشود.
• کیفیت کاهش نیابد.
• Product Backlog در صورت نیاز refine شود.
• محدوده ممکن است با یادگیری بیشتر با Product Owner شفاف و مذاکرهٔ مجدد شود.

طول خیلی بلند ریسک می‌سازد: هدف ممکن است بی‌اعتبار شود، پیچیدگی بالا برود، و هزینهٔ اشتباه بزرگ‌تر شود. Sprint کوتاه‌تر چرخه‌های یادگیری بیشتر و سقف ریسک کوچک‌تر می‌دهد. هر Sprint را می‌توان مانند یک پروژهٔ کوتاه دید.

لغو Sprint فقط در اختیار Product Owner است و وقتی معنا دارد که Sprint Goal منسوخ شده باشد — نه وقتی کار سخت شده است.

Sprint Goal: چرا قبل از فهرست کار

Sprint Goal هدف واحد Sprint است. اگرچه تعهد Developers است، در «چگونه» انعطاف می‌دهد. هدف انسجام می‌سازد تا تیم روی ابتکارات پراکنده تکه تکه نشود.

هدف خوب معمولاً به زبان ارزش یا نتیجه است نه فهرست فنی. مثال ضعیف: «پنج تیکت Frontend و سه تیکت Backend». مثال قوی‌تر: «کاربر بتواند بدون تماس پشتیبانی، رمز را با ایمیل بازیابی کند». دومی به تیم اجازه می‌دهد اگر جزئیات فنی غافلگیرکننده بود، مسیر را عوض کند بدون اینکه معنای Sprint از بین برود.

Sprint Planning — سه موضوع رسمی

Sprint Planning کار Sprint را پایه‌گذاری می‌کند و کل Scrum Team با هم برنامه را می‌سازند. PO مطمئن می‌شود شرکت‌کنندگان برای بحث مهم‌ترین آیتم‌های بک‌لاگ و پیوندشان با Product Goal آماده‌اند. افراد دیگر می‌توانند برای مشاوره دعوت شوند.

موضوع یک: چرا این Sprint ارزشمند است؟

PO پیشنهاد می‌کند محصول در این Sprint چگونه ارزش یا سودمندی‌اش را افزایش می‌دهد. کل تیم Sprint Goal را تعریف می‌کند. هدف باید قبل از پایان Planning نهایی شود.

موضوع دو: چه چیزی این Sprint Done می‌شود؟

Developers با گفت‌وگو با PO آیتم‌هایی از Product Backlog برمی‌گزینند. در همین فرایند ممکن است آیتم‌ها refine شوند تا فهم و اطمینان بالا برود. انتخاب حجم کار دشوار است؛ هرچه Developers عملکرد گذشته، ظرفیت پیش رو و Definition of Done را بهتر بشناسند، پیش‌بینی‌شان مطمئن‌تر می‌شود.

موضوع سه: کار انتخاب‌شده چگونه انجام می‌شود؟

برای هر آیتم انتخاب‌شده، Developers کار لازم برای ساخت Increment مطابق Done را برنامه‌ریزی می‌کنند — اغلب با شکستن به کارهای یک روز یا کمتر. چگونگی‌اش در اختیار خود Developers است؛ کس دیگری به آن‌ها دیکته نمی‌کند چگونه آیتم را به Increment تبدیل کنند.

Timebox Planning: حداکثر ۸ ساعت برای Sprint یک‌ماهه؛ برای Sprint کوتاه‌تر معمولاً کوتاه‌تر.

چگونه یک Sprint خوب را از قبل آماده کنیم

کیفیت Planning به کار قبل از اتاق جلسه وابسته است:

1. Product Goal روشن باشد تا Sprint در خلأ معنا نسازد.
2. بالای بک‌لاگ refine شده باشد: آیتم‌هایی که تیم باور دارد در یک Sprint قابل Done شدن‌اند.
3. ظرفیت واقعی معلوم باشد (مرخصی، پشتیبانی، کار عملیاتی).
4. Definition of Done در دسترس و معتبر باشد — نه شعار روی دیوار.
5. ذی‌نفعان کلیدی برای Review از قبل در تقویم باشند.

اگر Planning تبدیل به کشف اولیهٔ نیازمندی می‌شود، refinement کافی نبوده است. Guide می‌گوید آیتم‌هایی که تیم می‌تواند در یک Sprint به Done برساند، آمادهٔ انتخاب در Planning دانسته می‌شوند و معمولاً بعد از فعالیت‌های refining به این شفافیت می‌رسند.

در طول Sprint: Daily و تطبیق

Daily Scrum پانزده دقیقه برای Developers است تا پیشرفت به سمت Sprint Goal را بازرسی کنند و Sprint Backlog را در صورت نیاز تطبیق دهند. ساختار جلسه آزاد است؛ شرط این است که روی پیشرفت به هدف متمرکز باشد و برنامهٔ عملی روز بعد بسازد. Daily تنها زمان مجاز برای تنظیم برنامه نیست؛ گفت‌وگوهای جزئی‌تر در طول روز هم رایج‌اند.

اگر هر روز می‌فهمید هدف در خطر است، زود با PO دربارهٔ محدوده مذاکره کنید — نه اینکه در روز آخر کیفیت را قربانی کنید. Guide صریح می‌گوید کیفیت نباید پایین بیاید.

پایان Sprint: Review و Retrospective

Sprint Review نتیجه را بازرسی می‌کند و تطبیق‌های آینده را رقم می‌زند. تیم نتیجه را به ذی‌نفعان کلیدی نشان می‌دهد؛ پیشرفت به Product Goal بحث می‌شود؛ بک‌لاگ ممکن است برای فرصت‌های جدید تنظیم شود. این یک جلسهٔ کاری است نه فقط ارائه.

Sprint Retrospective راه‌های افزایش کیفیت و اثربخشی را برنامه‌ریزی می‌کند: افراد، تعاملات، فرایند، ابزار، و Definition of Done. مهم‌ترین بهبودها هرچه زودتر پیگیری می‌شوند و حتی ممکن است وارد Sprint Backlog بعد شوند. Retrospective Sprint را می‌بندد.

طول Sprint را چطور انتخاب کنیم؟

راهنمای عملی برای بسیاری از تیم‌های محصول نرم‌افزاری:

• دو هفته: تعادل رایج بین تمرکز و بازخورد؛ برای اکثر تیم‌های پایدار نقطهٔ شروع خوب.
• یک هفته: وقتی عدم‌قطعیت بالاست یا می‌خواهید ریسک را بسیار محدود کنید؛ هزینهٔ هماهنگی نسبی بالاتر است.
• سه تا چهار هفته: وقتی یکپارچگی‌ها سنگین‌اند و Done واقعی در بازهٔ کوتاه‌تر غیرواقعی است — با آگاهی از ریسک هدف منسوخ.

طول را هر Sprint عوض نکنید. ثبات به پیش‌بینی‌پذیری کمک می‌کند. اگر مدام به چهار هفته پناه می‌برید چون Done شما سنگین است، شاید مشکل طول Sprint نباشد؛ Definition of Done یا اندازهٔ آیتم‌هاست.

اشتباه‌های رایج برنامه‌ریزی

• پر کردن Sprint بدون Sprint Goal.
• تعهد تقویمی ثابت از بیرون («تا جمعه همه باید تمام شود») بدون مالکیت Developers روی پیش‌بینی.
• آوردن آیتم‌های مبهم «بعداً Clarification می‌کنیم».
• نادیده گرفتن کار عملیاتی و حمایت در ظرفیت.
• پایان Planning بدون فهم مشترک از Done برای آیتم‌های انتخاب‌شده.

چک‌لیست Sprint سالم

1. Sprint Goal در یک جمله قابل فهم برای ذی‌نفع غیرتکنیکال.
2. آیتم‌های انتخاب‌شده با معیار پذیرش یا مثال‌های روشن (مقالهٔ ۰۶۴).
3. ظرفیت و ریسک‌های شناخته‌شده روی میز.
4. Daily واقعاً حول هدف، نه دور گزارش به مدیر.
5. Review با تصمیم دربارهٔ بعد؛ Retrospective با حداقل یک بهبود پیگیری‌شدنی.

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

Sprint timebox ثابت برای تبدیل کار بک‌لاگ به Increment باارزش است، با حفظ کیفیت و هدف. برنامه‌ریزی خوب از «چرا» شروع می‌کند، «چه» را با ظرفیت و Done واقعی انتخاب می‌کند، و «چگونه» را به Developers می‌سپارد. اگر فقط یک بهبود این Sprint می‌خواهید: Sprint Goal را قبل از بستن فهرست تیکت‌ها بنویسید و در Daily آن را محور قرار دهید.

ظرفیت، پیش‌بینی و فشار بیرونی

Developers حجم کار Sprint را پیش‌بینی می‌کنند؛ این پیش‌بینی تعهد قراردادی بیرونی برای تاریخ ثابت قابلیت‌های نامحدود نیست. وقتی فروش یا مدیریت تاریخ اعلام‌شده دارد، سالم‌ترین مسیر این است که محدوده را با Sprint Goal و آیتم‌های ممکن هم‌تراز کنید، نه اینکه کیفیت یا Done را قربانی تاریخ کنید. Guide صریح می‌گوید کیفیت نباید کاهش یابد و تغییر نباید Sprint Goal را به خطر بیندازد.

اگر مدام Sprintها «نود درصد تمام» تمام می‌شوند، یا آیتم‌ها درشت‌اند، یا ظرفیت واقعی (پشتیبانی، جلسات، بدهی فنی) در Planning نادیده گرفته می‌شود. یک Sprint آزمایشی با ظرفیت صادقانه‌تر اغلب پیش‌بینی را بیشتر از هر تکنیک تخمین پیچیده بهبود می‌دهد.

Sprint و کار عملیاتی / تولید

تیم‌هایی که هم محصول می‌سازند هم Production را نگه می‌دارند، باید سهمی از ظرفیت را برای کار عملیاتی رزرو کنند یا جریان جدا برای حوادث تعریف کنند. بلعیده‌شدن Sprint توسط آتش‌نشانی مداوم یعنی یا پایداری ضعیف است یا Sprint Goal غیرواقعی. Retrospective جای درست برای دیدن این الگو و تصمیم دربارهٔ بهبود پایدار است — نه فقط شماتت افراد.

نمونهٔ یک Planning ۹۰ دقیقه‌ای برای Sprint دو هفته

1. ۱۰ دقیقه: یادآوری Product Goal و بازهٔ ظرفیت.
2. ۲۰ دقیقه: پیشنهاد ارزش Sprint و نوشتن پیش‌نویس Sprint Goal.
3. ۴۰ دقیقه: انتخاب آیتم‌های آماده، شفاف‌سازی سریع، رد آیتم‌های خام.
4. ۱۵ دقیقه: شکستن اولیهٔ کار و شناسایی ریسک‌ها.
5. ۵ دقیقه: تأیید نهایی Goal و فهرست، و زمان Review/Retro.

اگر ۹۰ دقیقه کافی نبود، معمولاً مشکل طول جلسه نیست؛ آماده‌نبودن بک‌لاگ است. زمان را بی‌نهایت تمدید نکنید — refinement را به تقویم برگردانید.

Sprint Goalهای نمونه و ضدنمونه

اگر نوشتن Goal سخت است، معمولاً بک‌لاگ مجموعه‌ای از کارهای پراکنده است نه یک برش منسجم ارزش. قبل از Planning، PO باید چند آیتم هم‌راستا را نزدیک بالای لیست آورده باشد.

هنگام تغییر اولویت وسط Sprint

بازار و حوادث واقعی رخ می‌دهند. مسیر سالم: PO و Developers محدوده را طوری مذاکره می‌کنند که Sprint Goal حفظ شود؛ اگر Goal دیگر معتبر نیست، لغو Sprint فقط با اختیار PO مطرح می‌شود. مسیر ناسالم: هر روز آیتم جدید از بالای سر تیم وارد Sprint Backlog می‌شود بدون مذاکره — این شفافیت را می‌کشد و Daily را بی‌معنا می‌کند.

برای سازمان‌هایی با درخواست‌های فوری زیاد، یک بافر ظرفیت یا جریان جدا برای کار فوری شفاف‌تر از خراب کردن هر Sprint است. این تصمیم را در Retro بگیرید نه در بحران.

ارتباط Sprint با Product Goal

هر Sprint باید قدمی به‌سوی Product Goal باشد، نه جزیره‌ای از کارهای متفرقه. در Planning موضوع یک («چرا این Sprint ارزشمند است؟») دقیقاً همین پیوند را می‌سازد. اگر چند Sprint پیاپی نتوانید توضیح دهید چگونه به Product Goal نزدیک شدید، یا Goal مرده است یا Sprintها بدون استراتژی محصول پر می‌شوند.

یک تمرین ساده در Review: یک اسلاید با Product Goal، وضعیت قبل، Increment این Sprint، و فرضیهٔ Sprint بعد. این سه دقیقه اغلب بیشتر از بیست تیکت بسته‌شده به ذی‌نفع جهت می‌دهد.

شاخص‌های سلامت Sprint — بدون وسواس متریک

• آیا Sprint Goal در Review قابل دفاع بود؟
• چند آیتم طبق Done تمام شد نه «تقریباً»؟
• آیا کیفیت برای رسیدن به تاریخ قربانی شد؟
• آیا حداقل یک بهبود Retro در Sprint بعد دیده شد؟

اگر این چهار مورد سبز باشند، حتی با velocity نوسانی، Sprint شما از نظر Guide سالم‌تر از تیمی است که نمودار قشنگ دارد و Done شل.

منابع و مراجع

• The 2020 Scrum Guide™ — The Sprint; Sprint Planning; Daily Scrum; Sprint Review; Sprint Retrospective — https://scrumguides.org/scrum-guide.html