چگونه مقادیر را در نمودار Burn Down در Scrum محاسبه کنیم

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

بیایید یک بار دیگر به یاد بیاوریم که این نمودار چگونه به نظر می‌رسد.

در این مثال یک اسپرینت ۱۰ روزه بررسی شده است. در آن می‌بینیم که ۲ روز گذشته است (زیرا فقط دو بخش اول با نمودار سبز رنگ‌آمیزی شده‌اند).

همچنین حجم کل اسپرینت را می‌بینیم - این یک خط چین است که نشان می‌دهد حجم کل اسپرینت در دوشنبه ساعت ۱۰:۰۰، سه‌شنبه ساعت ۱۰:۰۰ و چهارشنبه ساعت ۱۰:۰۰ تغییر نکرده و برابر ۱۷ SP (Story Points) است.

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

سوختن واقعی (نمودار سبز) کار واقعاً باقی‌مانده را نشان می‌دهد. یعنی اکنون تیم ۱ Story Point از ۱۷ موردی را که برای تکمیل موفقیت‌آمیز اسپرینت باید انجام شود، انجام داده است. انجام‌شده чаще всего به معنای وظیفه در وضعیت «Done» است (اینکه Done برای هر تیم چه معنایی دارد، تیم خودش تعیین می‌کند. حتی یک آرتیفکت ویژه وجود دارد به نام DOD - Definition Of Done - که برای هر تیم متفاوت است و در آن بسیار دقیق توضیح داده شده که معنای انجام شدن وظیفه چیست و می‌توان آن را به وضعیت «Done» منتقل کرد. بیشتر اوقات این یعنی «روی پروداکشن مستقر شده»، اما ممکن است نکاتی وجود داشته باشد. در کل، بر اساس نمودار فعلی می‌فهمیم که DOD فقط برای یک استوری انجام شده که تیم آن را ۱ SP ارزیابی کرده است.

سوختن ایده‌آل نشان می‌دهد که نمودار سوختن واقعی در صورت کار کاملاً یکنواخت باید در چه نقطه‌ای قرار داشته باشد. یعنی در این لحظه باید ۳ SP در صورت کار کاملاً یکنواخت انجام شده باشد.

گمان می‌کنم درک اینکه Story Pointچیست می‌تواند جالب باشد. در واقع، ۱ SP در یک تیم و ۱ SP در تیم دیگر می‌توانند حجم کار متفاوتی را پنهان کنند. برای مثال، ما تیم‌هایی با تعداد افراد یکسان داریم، اما یکی ظرفیت اسپرینت ۱۷ SP و دیگری ۳۵SP دارد. و این طبیعی است. مسئله این است که تیم خودش یک وظیفه مرجع را برای خود انتخاب می‌کند که نسبت به آن همه وظایف را در گرومینگ‌ها ارزیابی می‌کند (نام قدیمی - این یک جلسه هفتگی است که در آن PO User Stories را برای ارزیابی می‌آورد و تیم آن‌ها را از طریق پوکر برنامه‌ریزی ارزیابی می‌کند) (در SAFe این PBR است - Product Backlog Refinement).

بنابراین، می‌توانیم یک User Story مرجع داشته باشیم: «من، در نقش راننده خودرو، می‌خواهم پس از سوخت‌گیری خودرو، در صورت نیاز امکان دریافت رسید چاپ‌شده روی کاغذ را داشته باشم». توافق کنیم که این برای تیم ما ۸SP است. و وقتی PO یک User Story جدید را تعریف می‌کند که باید ارزیابی کنیم، آن را نسبت به وظیفه مرجع ارزیابی می‌کنیم. بر این اساس، استوری جدید ممکن است مثلاً توسط تیم ۵ SP ارزیابی شود و به همین ترتیب همه استوری‌های بک‌لاگ ارزیابی‌های خود را دریافت می‌کنند.

ظرفیت تیم بر اساس آمار محاسبه می‌شود. در ۱-۲ اسپرینت اول تعداد SP که تیم می‌بندد اندازه‌گیری می‌شود و میانگین محاسبه می‌شود، و برنامه‌ریزی بر اساس این مقدار انجام می‌شود (وقتی PO وظایف را از بک‌لاگ برای ظرفیت مشخصی در اسپرینت جمع می‌کند).

امیدوارم به اندازه کافی واضح توضیح داده باشم که مقادیر روی Burn Down Chart چگونه به دست می‌آیند.