با آنچه داری، هر کاری که می‌توانی انجام بده

در حال بارگذاری...

دوایتیفای
قیمت‌گذاری سازمانی تماس با ما
دوایتیفای برنامه ریزی و اجرای پروژه

Velocity در Scrum چیست؟ محاسبه سرعت تیم

به روز شده در آگوست 20, 2026 https://doitify.com/fa/planning-fa/scrum-velocity/
اشتراک‌گذاری لینک کپی شد!
چکیده

Velocity در Scrum چیست؟ محاسبه سرعت تیم با Story Point، کاربرد در برنامه‌ریزی اسپرینت و پیش‌بینی تحویل + اشتباهات رایج و مثال عددی. Velocity Scrum.

Velocity مجموع Story Point‌هایی است که تیم در یک اسپرینت واقعاً تمام می‌کند. از میانگین چند اسپرینت گذشته حساب می‌شود تا پایدار و قابل‌اتکا باشد.

Velocity Scrum از موضوعات کلیدی در مدیریت پروژه و کار تیمی است. چطور می‌دانید در اسپرینت بعدی چقدر کار می‌توانید بپذیرید؟ اگر بر اساس حدس یا اشتیاق برنامه‌ریزی کنید، یا اسپرینت ناتمام می‌ماند یا ظرفیت تیم هدر می‌رود. پاسخ درست، استفاده از یک معیار ساده اما قدرتمند است: Velocity. اما Velocity هم مثل هر معیار دیگری، فقط وقتی ارزشمند است که درست فهمیده و درست استفاده شود.

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

در این مقاله می‌بینید Velocity در Scrum چیست، با Story Point چطور محاسبه می‌شود، چطور از آن برای پیش‌بینی استفاده کنید و چه اشتباه‌هایی این معیار را بی‌معنا می‌کند.

Velocity در Scrum چیست؟ (پاسخ سریع)

Velocity (سرعت) مجموع امتیازهای داستان (Story Point) کارهایی است که تیم در یک اسپرینت واقعاً کامل و تحویل می‌کند. به‌طور عملی، میانگین Velocity چند اسپرینت گذشته، مبنای برنامه‌ریزی ظرفیت اسپرینت‌های بعد است.

Story Point چیست و چه ربطی به Velocity دارد؟

Velocity بر پایهٔ Story Point محاسبه می‌شود، پس اول باید بدانید Story Point چیست. Story Point یک واحد نسبی برای تخمین «اندازهٔ» کار است — نه ساعت، بلکه ترکیبی از پیچیدگی، حجم و ریسک کار.

مثال عددی: تیم سه کار دارد: یک تغییر کوچک در رنگ دکمه (۲ امتیاز)، یک صفحهٔ ورود (۵ امتیاز) و یک ادغام با درگاه پرداخت (۸ امتیاز). این عددها نمی‌گویند «۸ ساعت»، می‌گویند «ادغام پرداخت حدود ۴ برابر سخت‌تر از تغییر رنگ است». وقتی همهٔ این امتیازها در یک اسپرینت تمام شوند، جمعشان Velocity آن اسپرینت است.

همین امروز به دوایتیفای بپیوندید

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

چطور Velocity محاسبه می‌شود؟

فرمول ساده است:

> Velocity = مجموع Story Point‌های آیتم‌های کاملاً تمام‌شده در اسپرینت

مثال عددی: اگر تیم در یک اسپرینت، آیتم‌های ۳ + ۵ + ۸ امتیازی را کامل تمام کرده، Velocity این اسپرینت ۱۶ است. برای برنامه‌ریزی بعد، میانگین سه تا پنج اسپرینت گذشته را در نظر می‌گیرید:

اسپرینت امتیاز تمام‌شده
۱ ۱۴
۲ ۱۶
۳ ۱۵
میانگین ۱۵

پس ظرفیت برنامه‌ریزی اسپرینت بعد، تقریباً ۱۵ امتیاز است — نه بیشتر و نه خیلی کمتر.

چرا فقط کارهای «تمام‌شده» شمرده می‌شوند؟

این قاعدهٔ مهمی است که اغلب نادیده گرفته می‌شود. اگر کار نیمه‌کاره هم امتیاز بگیرد، Velocity دروغ می‌گوید و برنامه‌ریزی‌ها را خراب می‌کند.

مثال عددی: تیمی در اسپرینت روی آیتم‌های ۳، ۵ و ۸ امتیازی کار می‌کند. آیتم ۸ امتیازی ۸۰ درصد پیش رفته اما طبق تعریفِ انجام‌شده (DoD) تمام نیست. اگر آن را بشمارید، Velocity می‌شود ۱۶؛ اگر فقط تمام‌شده‌ها را بشمارید، می‌شود ۸. تفاوت این دو عدد، یعنی تفاوت بین یک اسپرینت بعدیِ واقع‌بینانه و یک اسپرینت ناتمام دیگر.

چرا Velocity مهم است؟

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

دو مثال واقعی از استفادهٔ Velocity

مثال ۱ — پیش‌بینی زمان تحویل: تیم محصول، Velocity میانگین ۲۰ امتیاز در اسپرینت دارد. صاحب محصول می‌خواهد بداند «قابلیت گزارش‌گیری» که حدود ۶۰ امتیاز تخمین زده شده، کی آماده می‌شود. با Velocity ۲۰، یعنی حدود ۳ اسپرینت. این پیش‌بینی به ذی‌نفعان کمک می‌کند انتظار واقع‌بینانه داشته باشند.

مثال ۲ — تشخیص افت فرایند: Velocity تیمی چهار اسپرینت پیاپی ۱۸، ۱۹، ۱۸ و ۱۷ بوده، اما ناگهان در اسپرینت پنجم به ۹ می‌رسد. این افت ناگهانی، یک سیگنال است: یا عضوی مرخصی طولانی گرفته، یا مانعی فنی سر راه است، یا تیمی اضافه‌کاری سنگینی کرده. تیم این موضوع را در رترو بررسی می‌کند و متوجه می‌شود زیرساخت قدیمی، سرعت ادغام کد را نصف کرده است.

مثال عددی سوم: برنامه‌ریزی ظرفیت اسپرینت

تیمی میانگین Velocity سه اسپرینت اخیرش ۲۴ امتیاز است. برای اسپرینت بعد، صاحب محصول ۴۰ امتیاز کار آماده کرده است. اگر تیم همهٔ آن را بپذیرد، به‌احتمال زیاد نیمی از کار ناتمام می‌ماند. تصمیم درست: حدود ۲۴ امتیاز را انتخاب کنید، بقیه را در بک‌لاگ نگه دارید و به‌جای تعهد بیش از حد، جا برای یک کار غیرمنتظره بگذارید.

نمودار Velocity چه می‌گوید؟

دیدن Velocity به‌صورت نمودار خطی یا ستونی در طول اسپرینت‌های متوالی، خیلی گویاتر از یک عدد منفرد است. سه الگوی رایج:

  • روند صعودی پایدار: نشانهٔ بلوغ تیم و بهبود فرایند است (خبر خوب).
  • نوسان شدید: یعنی برنامه‌ریزی یا تخمین بی‌ثبات است و باید بررسی شود.
  • افت ناگهانی: معمولاً نشانهٔ یک مانع یا تغییر در تیم است.

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

چرا Velocity بین تیم‌ها قابل مقایسه نیست؟

این یکی از رایج‌ترین سوءتفاهم‌هاست. Story Point یک واحد مطلق نیست؛ هر تیم مقیاس تخمین خودش را دارد. تیم الف ممکن است به یک کار مشخص ۵ امتیاز بدهد و تیم ب به همان کار ۱۳ امتیاز. بنابراین Velocity ۲۰ تیم الف و Velocity ۲۰ تیم ب، هیچ‌کدام «سریع‌تر» یا «بهتر» نیستند. Velocity فقط در بستر یک تیم واحد و تاریخچهٔ همان تیم معنا دارد.

جدول: کاربرد درست و نادرست Velocity

کاربرد درست یا نادرست
برنامه‌ریزی ظرفیت اسپرینت بعد درست
پیش‌بینی زمان تحویل درست
ارزیابی عملکرد فردی اعضا نادرست
مقایسهٔ سرعت دو تیم نادرست
هدف‌گذاری «Velocity را بیشتر کن» نادرست
تشخیص تغییر فرایند در رترو درست

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

  1. Velocity به‌عنوان سنجهٔ عملکرد فردی: Velocity مال تیم است، نه سنجهٔ ارزیابی پرسنل. اگر آن را به ارزیابی فردی وصل کنید، همکاری تیمی خراب می‌شود.
  2. مقایسهٔ بین تیم‌ها: هر تیم مقیاس تخمین خودش را دارد؛ عدد ۲۰ در دو تیم قابل مقایسه نیست.
  3. تخمینِ بالاتر برای «سرعت بیشتر»: این کار داده را خراب می‌کند و Velocity را بی‌معنا می‌کند.
  4. تکیه بر یک اسپرینت: Velocity باید از میانگین چند اسپرینت محاسبه شود.
  5. شمردن کار نیمه‌کاره: فقط آیتم‌های کاملاً تمام‌شده (طبق DoD) امتیاز دارند.

مزایا و محدودیت‌های Velocity

مزایا:

  • برنامه‌ریزی اسپرینت را از حدس به داده تبدیل می‌کند.
  • پیش‌بینی نسبتاً دقیقی از زمان تحویل می‌دهد.
  • تغییرات فرایند و سلامت تیم را زود نشان می‌دهد.

محدودیت‌ها و Trade-off:

  • فقط بر اساس تاریخچهٔ تیم خودش معنا دارد؛ برای تیم تازه‌کار، چند اسپرینت اول دادهٔ معتبری ندارد.
  • به کیفیت تخمین‌ها وابسته است؛ تخمین بد، Velocity بد می‌سازد.
  • یک «شاخص عقب‌مانده» است (Lagging Indicator) و نمی‌گوید چرا تغییر کرده — فقط نشان می‌دهد تغییر کرده است.
  • اگر به‌عنوان سنجهٔ فردی یا ابزار فشار به کار گرفته شود، به سرعت مخرب می‌شود.

نکات کاربردی

  • نکته مهم: فقط امتیاز آیتم‌های «کاملاً تمام‌شده» (طبق DoD) را بشمارید؛ کار نیمه‌کاره امتیاز ندارد.
  • ترفند کاربردی: Velocity را در یک نمودار دنبال کنید؛ روند صعودی پایدار بهتر از جهش‌های مقطعی است.
  • اشتباه رایج: مقایسهٔ Velocity فعلی با روزهای اول تیم؛ تیم در حال بلوغ، طبیعتاً تغییر می‌کند.
  • قبل از شروع این را بدانید: برای محاسبهٔ دقیق Velocity، Story Point هر آیتم باید در ابزار مدیریت اسپرینت ثبت و با وضعیت «تمام‌شده» جمع شود.

Velocity با ظرفیت (Capacity) چه فرقی دارد؟

این دو مفهوم نزدیک‌اند اما یکی نیستند و خلطشان برنامه‌ریزی را خراب می‌کند:

  • Velocity: یک عدد تاریخی است — تیم در اسپرینت‌های گذشته چه‌قدر تحویل داده است.
  • Capacity: یک عدد آینده‌نگر است — تیم در اسپرینت پیشِ رو واقعاً چه‌قدر ظرفیت دارد.

مثلاً اگر میانگین Velocity تیم ۲۰ باشد اما در اسپرینت بعد دو نفر از پنج نفر تیم در مرخصی باشند، Capacity کمتر از ۲۰ است. Velocity به شما نقطهٔ شروع می‌دهد، اما Capacity (با در نظر گرفتن غیبت‌ها و تعطیلات) برنامهٔ نهایی را می‌سازد.

چطور Velocity را بهبود دهیم؟

Velocity هدف نیست، نتیجهٔ کار بهتر است. پس نباید «Velocity را بالا ببریم» هدف شود؛ بلکه باید علت‌های کم‌بودن را رفع کنید:

  • گلوگاه‌ها را کم کنید: کارها را کوچک‌تر بشکنید تا زودتر تمام شوند.
  • وابستگی‌ها را کاهش دهید: وابستگی بین تیم‌ها، انتظار ایجاد می‌کند.
  • کیفیت را بالا ببرید: دوباره‌کاریِ کمتر یعنی کار تمام‌شدهٔ بیشتر.
  • پایداری تیم را حفظ کنید: جابه‌جایی اعضا، موقتاً Velocity را کم می‌کند.

اگر فقط فشار بیاورید «بیشتر امتیاز تمام کنید»، نتیجه معمولاً دستکاری تخمین‌هاست، نه کار بیشتر — و Velocity از کار می‌افتد.

جدول: Velocity در برابر Throughput کانبان

معیار Velocity (اسکرام) Throughput (کانبان)
واحد Story Point تعداد کار
چرخه هر اسپرینت هر هفته/ماه
وابستگی به تخمین بله خیر
کاربرد برنامه‌ریزی اسپرینت پیش‌بینی جریان

هر دو هدف مشترکی دارند — فهمیدن ظرفیت تیم — اما با منطق متفاوت. Velocity به تخمین‌های Story Point وابسته است؛ Throughput فقط می‌شمارد چند کار تمام شده، بدون نیاز به تخمین.

از چه زمانی Velocity قابل‌اتکا می‌شود؟

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

Velocity و تخمین دوباره‌کالیبره

یکی از خطاهای رایج این است که تیم بدون آگاهی، مقیاس تخمینش را در طول زمان عوض می‌کند. مثلاً داستانی که شش ماه پیش ۵ امتیاز بود، حالا چون تیم باتجربه‌تر شده، ۳ امتیاز تخمین زده می‌شود. نتیجه این می‌شود که Velocity به‌ظاهر ثابت یا حتی پایین‌تر می‌ماند، در حالی که تیم واقعاً سریع‌تر شده است. راه‌حل: هر از چند گاه (مثلاً هر چند اسپرینت) داستان مرجع را بازبینی کنید تا مقیاس تخمین، آگاهانه و پایدار بماند — نه اینکه بی‌سروصدا بلغزد.

Velocity و گفتگو با ذی‌نفعان

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

دوایتفای و محاسبهٔ سرعت

Velocity فقط وقتی دقیق است که امتیازها و وضعیت تکمیل به‌درستی ثبت شوند. در دوایتفای می‌توانید Story Point یا تخمین هر تسک را ثبت کنید، اسپرینت بسازید، وضعیت «انجام شد» را با QC و DOD کنترل کنید و از گزارش‌های پیشرفت برای دیدن سرعت واقعی تیم در طول زمان استفاده کنید. به این ترتیب برنامه‌ریزی اسپرینت‌ها بر پایهٔ داده است، نه حدس، و افت‌وخیزهای Velocity را هم می‌توانید سریع‌تر در رترو بررسی کنید.

سوالات متداول

مجموع Story Point‌هایی که تیم در یک اسپرینت کاملاً تمام می‌کند؛ میانگین چند اسپرینت آن، مبنای برنامه‌ریزی است.

جمع امتیاز آیتم‌های تمام‌شدهٔ اسپرینت؛ و برای برنامه‌ریزی، میانگین سه تا پنج اسپرینت گذشته.

واحد نسبی تخمین اندازهٔ کار (پیچیدگی + حجم + ریسک)، نه ساعت.

برنامه‌ریزی ظرفیت اسپرینت و پیش‌بینی زمان تحویل.

خیر؛ معیار تیمی است و برای ارزیابی پرسنل مناسب نیست.

خیر؛ مقیاس تخمین هر تیم متفاوت است.

خیر؛ فقط کارهای کاملاً تمام‌شده (طبق DoD).

معمولاً نشانهٔ یک مانع فنی، غیبت عضو یا تغییر فرایند است که باید در رترو بررسی شود.

جمع‌بندی

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

اگر موضوع Velocity Scrum برایتان مفید بود، پیشنهاد می‌کنیم مدیریت ریسک چیست؟ و نرم افزار مدیریت پروژه صنعتی را هم بخوانید.

همین امروز به دوایتیفای بپیوندید

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

0 0 رای ها
Article Rating
اشتراک‌گذاری
اشتراک در
اطلاع از
guest
0 Comments
قدیمی‌ترین
تازه‌ترین بیشترین رأی
فهرست مطالب

وقتش رسیده کارها را هوشمندتر پیش ببرید

پروژه‌ها، تیم و اهدافتان را در یک فضای کاری هوشمند کنار هم بیاورید و خیلی راحت‌تر به نتیجه برسید.

همین حالا شروع کنید
فهرست مطالب