راهنمای جامع برنامه‌ریزی اسپرینت: از تعهد تیم تا لایو شدن نسخه

در این مقاله می‌خوانید

1. اسپرینت چیست و چرا باید به نسخه گره بخورد
2. طول اسپرینت را یک بار انتخاب کنید و نگه دارید
3. پیش از جلسه: بک‌لاگ آماده، نه فهرست آرزوها
4. پالایش بک‌لاگ، کاری مداوم
5. چک‌لیست آمادگی کارت
6. جلسهٔ برنامه‌ریزی: سه پرسش
7. چرا: هدف اسپرینت را در یک جمله بنویسید
8. چه: ظرفیت را از گذشته بگیرید، نه از امید
9. چطور: کار را خرد کنید تا ریسک پیدا شود
10. چهار تاریخ که هر اسپرینت باید داشته باشد
11. تاریخ برنامه‌ای را بعد از شروع عوض نکنید
12. در طول اسپرینت: وقتی برنامه به هم می‌خورد
13. کار اضطراری وارد شد
14. هدف اسپرینت در خطر است
15. کارهای نیمه‌تمام آخر اسپرینت
16. تعریف تمام‌شده: یک فهرست، برای همه
17. بازبینی و بازنگری: حلقه را ببندید
18. اسپرینت روی تابلو: دو چیدمان عملی
19. دستور کار جلسه برای اسپرینت دوهفته‌ای
20. خطاهای رایج
21. جمع‌بندی
22. منابع و مطالعهٔ بیشتر

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

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

اسپرینت چیست و چرا باید به نسخه گره بخورد

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

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

تیمی که فقط اولی و دومی را برنامه‌ریزی می‌کند، معمولاً خیال می‌کند سر وقت است، در حالی که مشتری هنوز نسخه را ندیده. به همین دلیل در این راهنما اسپرینت را همیشه با نسخه‌اش در نظر می‌گیرم: اسپرینت v2.4، نه «اسپرینت ۱۲».

طول اسپرینت را یک بار انتخاب کنید و نگه دارید

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

پیش از جلسه: بک‌لاگ آماده، نه فهرست آرزوها

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

پالایش بک‌لاگ، کاری مداوم

راهنمای اسکرام پالایش بک‌لاگ محصول (Backlog Refinement) را فعالیتی مداوم می‌داند: شکستن کارهای بزرگ، روشن کردن جزئیات و مرتب کردن اولویت‌ها. در عمل یعنی مالک محصول و یکی دو نفر از تیم، در طول اسپرینت جاری، کارهای اسپرینت بعدی را آماده می‌کنند. یک جلسهٔ کوتاه در میانهٔ اسپرینت برای این کار معمولاً از یک جلسهٔ برنامه‌ریزی چهارساعته کارآمدتر است.

چک‌لیست آمادگی کارت

کارتی وارد جلسهٔ برنامه‌ریزی شود که:

• عنوانش نتیجه را بگوید، نه موضوع را.
• معیار پذیرش قابل بررسی داشته باشد؛ چیزی که تست‌کننده و مشتری بتوانند بگویند «بله، این کار می‌کند» یا «نه».
• آن‌قدر کوچک باشد که در چند روز تمام شود.
• وابستگی‌های بیرونی‌اش روشن باشد: دسترسی، طراحی، جواب مشتری، سرویس تیم دیگر.
• کسی در تیم بتواند تقریباً بگوید چقدر کار است.

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

جلسهٔ برنامه‌ریزی: سه پرسش

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

چرا: هدف اسپرینت را در یک جمله بنویسید

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

• ضعیف: «انجام کارت‌های ۱۴۲ تا ۱۵۸.»
• بهتر: «واحد مالی بتواند گزارش ماهانه را بدون کپی دستی، به اکسل بگیرد و برای مدیر بفرستد.»

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

چه: ظرفیت را از گذشته بگیرید، نه از امید

بهترین پیش‌بینی برای اینکه تیم در این اسپرینت چقدر کار تمام می‌کند، مقداری است که در اسپرینت‌های اخیر تمام کرده. مارتین فاولر این ایده را «آب‌وهوای دیروز» (Yesterday’s Weather) می‌نامد: هواشناسی که بگوید «فردا مثل امروز است»، بیشتر وقت‌ها درست می‌گوید. اگر تیم در سه اسپرینت اخیر به‌طور متوسط ۱۸ کارت هم‌اندازه تمام کرده، برنامه‌ریزی ۳۰ کارت، امید است نه برنامه.

بعد این عدد را برای همین اسپرینت تنظیم کنید. فرض کنید تیمی پنج‌نفره، اسپرینت دوهفته‌ای با ۱۰ روز کاری دارد:

مورد	محاسبه	نفر‌روز
ظرفیت خام	۵ نفر × ۱۰ روز	۵۰
مرخصی	یک نفر ۳ روز	۳ کم
تعطیل رسمی در بازه	۱ روز × ۵ نفر	۵ کم
ظرفیت این اسپرینت		۴۲
نسبت به اسپرینت معمولی	۴۲ از ۵۰	حدود ۸۴٪

یعنی اگر تیم معمولاً ۱۸ کارت تمام می‌کند، این بار حدود ۱۵ کارت برنامه‌ریزی کنید. این اعداد مثال‌اند؛ مهم روش است: پایه از تجربهٔ خود تیم، تنظیم با تقویم واقعی. در تقویم ایرانی این تنظیم اهمیت بیشتری دارد؛ اسپرینتی که با نوروز یا تعطیلات پشت‌سرهم مذهبی هم‌پوشانی دارد، اسپرینت معمولی نیست و نباید مثل آن برنامه‌ریزی شود.

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

چطور: کار را خرد کنید تا ریسک پیدا شود

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

قاعدهٔ من: اگر هیچ‌کس در تیم نمی‌تواند قدم اول یک کارت را بگوید، آن کارت آمادهٔ اسپرینت نیست.

چهار تاریخ که هر اسپرینت باید داشته باشد

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

نقطهٔ عطف	معنا	چه کسی تأییدش می‌کند
شروع توسعه	تیم روی کارهای این نسخه کار را آغاز کرده	سرپرست تیم
پایان توسعه	همهٔ کارهای نسخه تعریف تمام‌شده را دارند	سرپرست تیم و تست‌کننده
ورود به آزمون کاربر (UAT)	نسخه روی محیط آزمون مشتری نصب و به او اعلام شده	مسئول انتشار
لایو شدن نسخه	نسخه روی محیط اصلی است و کاربران از آن استفاده می‌کنند	مسئول انتشار و مالک محصول

نمونه‌ای از اینکه این جدول در عمل چه شکلی پیدا می‌کند، برای نسخهٔ فرضی v2.4:

نقطهٔ عطف	برنامه‌ای	واقعی	اختلاف
شروع توسعه	۵ مهر	۵ مهر	—
پایان توسعه	۱۴ مهر	۱۵ مهر	۱ روز تأخیر
ورود به UAT	۱۵ مهر	۱۸ مهر	۳ روز تأخیر
لایو شدن	۲۲ مهر	—	در انتظار

همین جدول کوچک چیزی را نشان می‌دهد که در گزارش «توسعه تقریباً سر وقت تمام شد» گم می‌شد: تأخیر اصلی بین پایان توسعه و ورود به UAT بوده، یعنی در آماده‌سازی محیط مشتری یا بسته‌بندی نسخه، نه در کدنویسی. بدون ثبت جداگانهٔ این دو تاریخ، تیم در بازنگری دنبال مشکل در جای اشتباه می‌گشت.

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

در بردماگ هر ستون را می‌شود ستون اسپرینت کرد، با نام نسخه و تاریخ برنامه‌ای و واقعی همین چهار نقطهٔ عطف به تقویم شمسی؛ سرستون وضعیت نسخه، شمارش معکوس (مثلاً «۳ روز تا ورود به UAT») و تأخیر را نشان می‌دهد. ولی همین جدول در یک صفحه‌گسترده هم، اگر با نظم پر شود، بیشتر فایده را دارد.

تاریخ برنامه‌ای را بعد از شروع عوض نکنید

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

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

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

در طول اسپرینت: وقتی برنامه به هم می‌خورد

برنامه همیشه به هم می‌خورد. سؤال این است که تیم چطور واکنش نشان می‌دهد.

کار اضطراری وارد شد

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

هدف اسپرینت در خطر است

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

کارهای نیمه‌تمام آخر اسپرینت

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

تعریف تمام‌شده: یک فهرست، برای همه

راهنمای اسکرام «تعریف تمام‌شده» (Definition of Done) را تعهدی می‌داند که مشخص می‌کند یک افزوده کی کیفیت لازم را دارد. بدون آن، «پایان توسعه» در جدول نقاط عطف بی‌معنی است، چون هر کس منظور خودش را دارد. یک نمونه برای تیمی که نسخه به UAT مشتری می‌دهد:

1. کد بازبینی شده و در شاخهٔ اصلی ادغام شده است.
2. تست‌های خودکار مرتبط نوشته شده و سبزند.
3. تست‌کنندهٔ تیم معیارهای پذیرش کارت را روی محیط تست داخلی بررسی کرده است.
4. تغییرات دیتابیس به‌صورت اسکریپت قابل اجرا روی محیط مشتری آماده است.
5. یادداشت انتشار برای کاربر نهایی، به فارسی ساده، نوشته شده است.

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

بازبینی و بازنگری: حلقه را ببندید

در بازبینی اسپرینت (Sprint Review) تیم آنچه ساخته را به ذی‌نفعان نشان می‌دهد و بازخورد می‌گیرد. نشان دادن یعنی نرم‌افزار در حال کار، نه اسلاید. اگر نسخه هنوز در UAT است، همان را نشان دهید و بگویید چه زمانی لایو می‌شود.

در بازنگری اسپرینت (Sprint Retrospective) تیم دربارهٔ خودِ شیوهٔ کار حرف می‌زند. اینجاست که جدول چهار تاریخ ارزش واقعی‌اش را نشان می‌دهد. به‌جای «حس می‌کنم این اسپرینت شلوغ بود»، تیم می‌تواند بگوید: «در سه نسخهٔ اخیر، پایان توسعه تقریباً سر وقت بوده ولی ورود به UAT هر بار دو سه روز عقب افتاده.» این جمله یک مسئلهٔ مشخص است که می‌شود برایش راه‌حل پیدا کرد.

از هر بازنگری یک تغییر، فقط یکی، برای اسپرینت بعد بیرون بیاورید و در اسپرینت بعدی ببینید اثر داشت یا نه. فهرست ده‌تایی «باید بهتر شویم» که هیچ‌کدامش پیگیری نمی‌شود، فقط ناامیدی می‌آورد.

اسپرینت روی تابلو: دو چیدمان عملی

اسپرینت را روی تابلو معمولاً به یکی از این دو شکل نشان می‌دهند:

• یک تابلو برای هر نسخه. ستون‌ها مراحل جریان کارند (آمادهٔ شروع، در حال توسعه، بازبینی، تست، تمام). برای تیم‌هایی مناسب است که هر بار فقط روی یک نسخه کار می‌کنند. عیبش این است که تاریخچهٔ نسخه‌ها در تابلوهای جدا پخش می‌شود.
• یک ستون برای هر نسخه. بک‌لاگ در یک ستون است، هر نسخه ستون خودش را دارد و کارت‌هایی که برای آن نسخه متعهد شده‌اند به آن ستون می‌روند. وضعیت جزئی هر کارت با برچسب یا تاریخ‌هایش نشان داده می‌شود. برای تیم‌هایی مناسب است که هم‌زمان یک نسخه در UAT و نسخهٔ بعدی در توسعه دارند، که در کار با مشتری سازمانی بسیار رایج است.

هیچ‌کدام درست مطلق نیست. اگر تیم شما بیشتر جریان پیوسته دارد تا نسخه‌های دوره‌ای، شاید اصلاً اسپرینت لازم نداشته باشید؛ مقایسهٔ اسکرام و کانبان کمک می‌کند این را تصمیم بگیرید.

دستور کار جلسه برای اسپرینت دوهفته‌ای

این ترتیب را با بک‌لاگ آماده، در حدود دو ساعت می‌شود اجرا کرد. زمان‌ها پیشنهادی‌اند:

1. مرور اسپرینت قبل (۱۰ دقیقه): جدول چهار تاریخ نسخهٔ قبل، کارهای منتقل‌شده و دلیلش.
2. ظرفیت این اسپرینت (۱۰ دقیقه): میانگین کار تمام‌شده در سه اسپرینت اخیر، تنظیم با مرخصی‌ها و تعطیلات.
3. هدف اسپرینت (۱۵ دقیقه): مالک محصول پیشنهاد می‌دهد، تیم می‌پرسد و در یک جمله توافق می‌شود.
4. انتخاب کارها (۳۰ دقیقه): از بالای بک‌لاگ مرتب‌شده، تا جایی که ظرفیت اجازه می‌دهد. هر کارتی که هدف را پیش نمی‌برد، دلیل خوبی برای ماندن لازم دارد.
5. خرد کردن و ریسک‌ها (۳۰ دقیقه): برای هر کارت بزرگ، قدم اول و وابستگی‌های بیرونی.
6. تاریخ‌های نسخه (۱۰ دقیقه): چهار تاریخ برنامه‌ای را تعیین و ثبت کنید. تاریخ ورود به UAT را پیش از اعلام به مشتری با مسئول انتشار هماهنگ کنید.
7. جمع‌بندی (۵ دقیقه): یک نفر هدف، فهرست کارها و تاریخ‌ها را بلند می‌خواند. اگر کسی مخالف است، همین حالا بگوید.

خطاهای رایج

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

بند آخر بیش از آنکه مسئلهٔ فرایند باشد، مسئلهٔ همکاری است؛ در راهنمای همکاری در تیم نرم‌افزاری به آن پرداخته‌ام.

جمع‌بندی

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

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

منابع و مطالعهٔ بیشتر

• The Scrum Guide — متن رسمی راهنمای اسکرام: تعریف اسپرینت، برنامه‌ریزی، هدف اسپرینت و تعریف تمام‌شده.
• Yesterday’s Weather — Martin Fowler — چرا ظرفیت اسپرینت بعد را باید از کار تمام‌شده در اسپرینت قبل گرفت.
• Planning fallacy — Wikipedia — خطای برنامه‌ریزی و اینکه چرا برآوردهای ما از کار خودمان خوش‌بینانه است.
• Acceptance testing — Wikipedia — آزمون پذیرش و جایگاه آزمون پذیرش کاربر پیش از انتشار.