آموزش اسکرام؛ قسمت سوم: اسپرینت و برنامه‌ریزی

همان‌طورکه در قسمت قبل گفتیم، «اسپرینت» قلب رویکرد اسکرام است. اسپرینت معمولا با عنوان تایم‌باکس یا بازه‌ی زمانی کوتاه‌تر از یک ماه تعریف می‌شود که طی آن، نسخه‌ای بهبودیافته از محصول کاربردی آماده می‌شود. طول دوره‌ی اسپرینت‌ها در هر پروژه‌ی توسعه‌ی نرم‌افزار ثابت می‌ماند. هر اسپرینت جدید بلافاصله پس از نتیجه‌گیری اسپرینت قبلی آغاز می‌شود. رویدادهای اسپرینت‌ جلسات برنامه‌ریزی اسپرینت (Sprint Planning)، اسکرام‌های روزانه (Daily Scrums)، کار توسعه، جلسات مرور اسپرینت (Sprint Review) و جلسه‌ی بازنگری اسپرینت (Sprint Retrospective) را شامل می‌شوند. در طول اسپرینت:

• هیچ تغییری اعمال نمی‌شود که هدف را به‌خطر بیندازد.
• اهداف کیفی تنزیل نمی‌یابند.
• محدوده‌ی کار مشخص‌ می‌شود و اگر اطلاعات بیشتری به‌دست آید، مالک محصول و تیم توسعه درباره‌ی آن باردیگر مذاکره می‌کنند.

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

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

اسکرام اسپرینت (Scrum Sprint) تمام عناصر مرتبط با اسکرام را شامل می‌شود. درحقیقت، اسکرام اسپرینت فرایندی متوالی با تکرارهای متوالی است؛ به‌طوری‌که هر چرخه بلافاصله پس از اتمام چرخه‌ی قبل آغاز می‌شود و این روند بدون وقفه تا زمانی‌ ادامه می‌یابد که محصول نهایی عرضه شود.

پس از تعاریف اولیه، بهتر است نگاه دقیق‌تری به جزئیات بیندازیم تا کاری را درک کنیم که واقعا در اسکرام اسپرینت انجام می‌دهیم.

تایم‌باکس‌شدن: از منظر تایم‌باکسینگ، اسپرینت‌ها ثابت هستند و مشخصه‌ی رویکرد مدیریت زمان آن‌ها، به مدیریت دامنه و سازمان‌دهی عملکرد کار کمک می‌کند. هریک از اسپرینت‌ها، می‌تواند در فریم زمان ثابت با تاریخ‌های شروع و پایان مشخص به‌نام «تایم‌باکس» تکمیل شود.

تعیین محدوده‌ی WIP: تایم‌باکسینگ یکی از فنون حفظ محدودیت کار در جریان (WIP) است. این WIP فهرستی از کارهایی را نشان می‌دهد که آغازشده، اما هنوز به‌پایان نرسیده است. اگر موفق نشویم این فهرست را به‌درستی مدیریت کنیم، با پیامدهای جدی اقتصادی مواجه می‌شویم. تایم‌باکسینگ محدودیت WIP را برای هر اسپرینت حفظ می‌کند.

تکنیک تایم‌باکسینگ: پومودورو یکی از تکنیک‌های رایج زمان‌بندی است. همان‌طورکه در این مطلب شرح داده‌ایم، پومودورو شامل بازه‌های کوتاه‌مدت کار سخت (معمولا ۲۵ دقیقه) و پس‌ازآن استراحتی کوتاه‌مدت است. اگر نتوانید کار خود را در تایم‌باکس مخصوص به‌پایان برسانید، می‌توانید آن را تا زمانی‌ ادامه دهید که به هدف برسید. باوجوداین باید مطمئن شوید پیشرفت کار را پس از هربار پایان تایم‌باکس بررسی می‌کنید. تکنیک پومودورو کمک می‌کند بهره‌وری خود را افزایش دهید و با انگیزه و قدرت بیشتری برای رسیدن به مقصد تلاش کنید.

اولویت‌بندی نیروها: تایم‌باکسینگ ما را وادار می‌کند نیروها و کارهای هرچند کوچک را اولویت‌بندی کنیم. این، تمرکز تیم را افزایش می‌دهد. درنتیجه، ما سریع‌تر به‌سمت تکمیل کار یا ساخت خروجی ارزشمند (محصول) حرکت می‌کنیم.

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

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

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

بهبود پیش‌بینی‌پذیری: تایم‌باکسینگ پیش‌بینی‌پذیری را نیز تقویت می‌کند. ما نمی‌توانیم دقیقا کاری را پیش‌بینی کنیم که در طول یک سال انجام می‌دهیم؛ ولی به‌طور منطقی می‌توانیم میزان کار تکمیل‌شده در هر اسپرینت کوتاه آتی را برآورد کنیم.

بازه‌های کوتاه‌مدت: ما مزایای بیشتری در اسپرینت‌ها کوتاه‌مدت به‌دست می‌آوریم؛ زیرا قادریم میزان پیشرفت خود را در فواصل کوتاه ردیابی کنیم.

سهولت برنامه‌ریزی: طبیعتا برنامه‌ریزی برای چند هفته کار (اسپرینت) درمقایسه‌با شش ماه کار آسان‌تر است. همچنین، تلاشی که برای برنامه‌ریزی کوتاه‌مدت می‌شود، درمقایسه‌با برنامه‌ریزی‌های افق بلندمدت کمتر است.

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

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

شرکت‌کنندگان در اسپرینت، معمولا این افراد هستند:

• مالک محصول
• اسکرام مستر
• تیم توسعه

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

• تحویل موفقیت‌آمیز محصول برای رسیدن به هدف اسپرینت
• تدابیر و اقدامات کیفی مناسب
• پذیرفته‌نبودن تغییر و تمدید به‌تأخیرافتادن احتمالی کارها
• ارائه‌ی بازخورد باکیفیت درباره‌ی ارزش تحویل‌داده‌شده
• اندازه‌گیری‌کردن سرعت حرکت تیم

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

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

• برنامه‌ریزی مبتنی بر سرعت
• برنامه‌ریزی مبتنی بر ظرفیت

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

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

بک‌لاگ محصول (Product Backlog): فهرستی رتبه‌بندی‌شده از کارهایی است که باید انجام شود تا محصولی ساخته یا حفظ شود. بک‌لاگ محصول را مالک محصول مدیریت می‌کند.

داستان یا استوری کاربر (User Story): توصیفی ساده از الزامات سیستم یا به‌بیانِ‌ساده، درخواست‌های مشتری است که معمولا در قالب چنین جمله‌ای بیان می‌شود: من (کاربر) می‌خواهم کاری انجام دهم (عملکرد) تا مزایایی (ارزش) به‌دست آورم.

استوری‌پوینت (Story Point): مقیاسی انتزاعی از تلاش‌هایی است که برای اجرای داستان کاربر انجام می‌شود.

برنامه‌ریزی مبتنی بر ظرفیت یا تعهد برپایه‌ی ظرفیت آزاد و دردسترسی است که تیم برای اسپرینت دراختیار دارد (برحسب ساعت). در این برنامه‌ریزی، تلاش می‌کنیم ظرفیت تیم را تاحدممکن به‌طور مؤثر و کارا پرکنیم، بدون اینکه فشار و بار زیادی به اعضای تیم تحمیل کنیم. برنامه‌ریزی مبتنی بر ظرفیت به سه دلیل بهترین نوع برنامه‌ریزی برای اسپرینت است:

۱. ظرفیت تیم طی اسپرینت‌های مختلف متفاوت است؛ زیرا عواملی مانند تعطیلات و از‌دست‌دادن برخی از اعضای تیم یا سایر تعهدات روی آن تأثیر می‌گذارد. بنابراین، نمی‌توانیم اسپرینت حد وسط را در نظر بگیریم و براساس آن برنامه‌ریزی و تصمیم‌گیری کنیم.

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

۳. درنهایت در برنامه‌ریزی اسپرینت، داستان‌های کاربر به تیم توسعه و مالک محصول اجازه می‌دهد با درنظرگرفتن همه‌ی جزئیات به درک مشترکی از محصول نهایی برسند.

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

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

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

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

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

تیمی ۶ نفره در اسپرینتی سه‌هفته‌ای (۱۵ روز) هرروز ۸ ساعت کار می‌کنند. پس، ظرفیت کلی تیم عبارت است از:

ظرفیت تیم = تعداد اعضای تیم × زمان برحسب ساعت × روز  

= ۶ × ۸ × ۱۵

=۷۲۰ ساعت

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

پس، چگونه می‌فهمیم تیم با چه ظرفیتی متعهد می‌شود؟ تیم چگونه می‌تواند کارایی رویدادهای برنامه‌ریزی اسپرینت را افزایش دهد؟ اینجا عامل تمرکز (F.F) را برای محاسبه‌ی ظرفیت واقعی تیم وارد می‌کنیم. عامل تمرکز به‌صورت ضریبی بین ۰.۶ تا ۰.۸ در نظر گرفته می‌شود.

مدیران پروژه معمولا در برنامه‌ریزی‌های خود ‌هرروز را بین ۶ تا ۶.۵ ساعت اجرایی در نظر می‌گیرند. بنابراین، عامل تمرکز معادل است با توانایی تیم برای متمرکزماندن و حرکت سریع به‌سمت اهداف بدون هیچ مانعی. در مثال مذکور، اگر عامل تمرکز را ۰.۶ در نظر بگیریم، ظرفیت واقعی تیم برابر است با ۷۲۰ × ۰.۶ = ۴۳۲ ساعت.

تیم ما می‌تواند در اسپرینت فعلی، ۴۳۲ ساعت کار کند. حالا تیم مهم‌ترین اولویت‌هایی را انتخاب می‌کند که مدیر محصول معرفی‌ و این استوری‌ها را به «وظایف» تقسیم می‌کند. دراین‌صورت، می‌توانیم مدت هر وظیفه را برحسب ساعت برآورد کنیم؛ بنابراین، تیم استوری‌ها را تا جایی متقبل می‌شود که مدت کلی آن‌ها از ۴۳۲ ساعت فراتر نرود.

اگر عامل تمرکز را نرخ پایینی در نظر گرفتیم و اعضای تیم همه‌ی آیتم‌های اسپرینت فعلی را به‌پایان رساندند، می‌توانند وظایف جدیدی بپذیرند. پس‌ازمدتی، تیم‌ها می‌توانند باتوجه‌به اسپرینت‌های قبلی، عامل تمرکز را افزایش دهند. باوجوداین، درنظرگرفتن ضریب بیش از ۰.۸ خطر را افزایش می‌دهد و ممکن است سرعت تیم را نیز کُند کند.

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

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

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

در برنامه‌ریزی مبتنی بر سرعت، باید مراحل زیر را طی کنیم:

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

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

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

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

فرض کنیم تیم با هدف محاسبه‌ی سرعت اسپرینتی یک‌هفته‌ای انجام می‌دهد.

اسپرینت اول

تیم به ۵ داستان کاربر متعهد شده که هر داستان ‌معادل ۸ استوری‌پوینت است؛ بنابراین، مجموعا در این اسپرینت با ۴۰ استوری‌پوینت سروکار داریم. در پایان اسپرینت، تیم موفق می‌شود ۳ داستان کاربر را تکمیل کند.

مجموع داستان‌های تکمیل‌شده‌ی کاربر = ۳

مجموع استوری‌پوینت‌های تکمیل‌شده: ۲۴ (تعداد کل داستان‌های تکمیل‌شده‌ی کاربر x استوری‌پوینت‌ها = ۴ × ۸)

اسپرینت دوم

تیم به ۷ داستان کاربر متعهد می‌شود و هر استوری کاربر معادل ۸ استوری‌پوینت است. پس در اسپرینت دوم، مجموعا ۴۲ استوری‌پوینت داریم. در اسپرینت دوم، تیم موفق می‌شود ۴ داستان کاربر را تکمیل کند.

مجموع داستان‌های تکمیل‌شده‌ی کاربر = ۴

مجموع استوری‌پوینت‌های تکمیل‌شده = ۳۲ (تعداد کل داستان‌های تکمیل‌شده کاربر x استوری‌پوینت‌ها = ۴ × ۸)

اسپرینت سوم

تیم به ۹ داستان کاربر متعهد می‌شود و هر داستان معادل ۸ استوری‌پوینت است؛ بنابراین در اسپرینت سوم، مجموعا با ۷۲ استوری‌پوینت رو‌به‌رو هستیم. در پایان اسپرینت سوم، تیم موفق می‌شود ۵ داستان کاربر را تکمیل کند.

مجموع داستان‌های تکمیل‌شده‌ی کاربر = ۵

مجموع استوری‌پوینت‌های تکمیل‌شده = ۴۰ (تعداد کل داستان‌های تکمیل‌شده کاربر x استوری‌‌پوینت‌ها = ۵ × ۸)

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

حالا سرعت متوسط ۳ اسپرینت بالا را محاسبه می‌کنیم. ما سرعت اسپرینت‌های قبلی را دراختیار داریم:

اسپرینت اول: ۲۴

اسپرینت دوم: ۳۲

اسپرینت سوم: ۴۰

۳÷ (۴۰+۳۲+۲۴) = ۳۲ سرعت متوسط اسپرینت

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

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

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

پیگیری وضعیت کلی پروژه: نمودار سرعت تعدادی از روند پروژه‌ها را شامل می‌شود؛ مثلا داستان‌های پذیرفته‌شده براساس نوع و متریک‌های نوسان پذیری و سرعت دوره. به‌همین‌دلیل، نمودار سرعت ابزار ایده‌آلی برای نظارت بر وضعیت کلی پروژه است.

ردیابی نوسانات: نوسان‌ها معیار سنجش پیش‌بینی‌پذیری هستند. اوج و فرودهای مکرر ممکن است نشان‌دهنده‌ی پروژه‌ای پیش‌بینی‌نشدنی باشند. این درحالی‌ است که ثبات نسبی نمودار به پروژه‌ای پیش‌بینی‌شدنی اشاره می‌کند.

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