تمرین تیم‌سازی در چارچوب Scrum

حرکت از Velocity به تصمیم‌های شواهد-محور، وقتی معیارها باید به Outcome پاسخ بدهند

بازاندیشی در مورد Velocity با نگاه EBM و Flow Metrics

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

EBM دقیقاً از همین‌جا شروع می‌کند:
اگر یک معیار باعث تصمیم‌های ضعیف، رفتارهای دفاعی و توهم قطعیت می‌شود، حتی اگر رایج باشد، باید مورد بازنگری قرار بگیرد.

خطای بنیادین Velocity از نگاه EBM

EBM چهار بُعد ارزش را محور تصمیم‌گیری می‌داند:

  • Current Value – ارزشی که همین حالا تحویل می‌دهیم
  • Unrealized Value – ارزشی که هنوز آزاد نشده
  • Time to Market – سرعت یادگیری و واکنش
  • Ability to Innovate – توان تغییر و نوآوری پایدار

Velocity تقریباً به هیچ‌کدام از این‌ها پاسخ مستقیم نمی‌دهد.

  • Velocity ارزش را اندازه نمی‌گیرد؛ فقط تلاش نسبی را نشان می‌دهد
  • Velocity زمان واقعی تحویل را نشان نمی‌دهد
  • Velocity ریسک و عدم‌قطعیت را پنهان می‌کند
  • Velocity یادگیری را قابل مشاهده نمی‌کند

در بهترین حالت، Velocity یک شاخص داخلی ظرفیت گذشته است؛
در بدترین حالت، یک عدد فریبنده که باعث تصمیم‌گیری اشتباه می‌شود.

نقد اصلی مقاله: مسئله Velocity نیست، مسئله «نوع گفت‌وگو»ست

نکته‌ی مهم مقاله این است که به‌جای حذف ناگهانی Velocity، می‌خواهد گفت‌وگو را اصلاح کند.
این رویکرد از نظر تغییر سازمانی هوشمندانه است، اما از دید EBM یک محدودیت جدی دارد:

اصلاح گفت‌وگو بدون اصلاح «معیارهای تصمیم‌گیری»، فقط درد را به تعویق می‌اندازد.

Velocity اگر هم «پیش‌بینی» شود، باز هم:

  • بر تلاش تمرکز دارد، نه ارزش
  • بر گذشته تکیه می‌کند، نه جریان واقعی تحویل
  • به‌سختی با تصمیم‌های استراتژیک هم‌راستا می‌شود

EBM می‌گوید:
معیارها باید مستقیماً به تصمیم‌های سرمایه‌گذاری، اولویت‌بندی و توقف یا ادامه‌ی کار وصل شوند.

Velocity این اتصال را ندارد.

حرکت از عدد ثابت به بازه

تبدیل Velocity از «عدد میانگین» به بازه (Best / Typical / Worst) یک گام درست است.
این کار دو اتفاق مهم می‌افتد:

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

اما از منظر EBM این فقط یک گام انتقالی است، نه مقصد.

Flow Metrics: آن‌چه Velocity هرگز نبود

Flow Metrics مستقیماً به سؤالات EBM پاسخ می‌دهند:

سؤال مدیریتیVelocityFlow Metrics
چقدر سریع ارزش تحویل می‌دهیم؟✅ Flow Time
چقدر کار واقعاً تمام می‌شود؟✅ Throughput
کجا گلوگاه داریم؟✅ WIP
ریسک تأخیر کجاست؟✅ Flow Load
آیا می‌توانیم پیش‌بینی کنیم؟⚠️ ضعیف✅ Probabilistic Forecast

Velocity «چقدر کار کردیم» را می‌گوید.
Flow Metrics می‌گویند:

  • کار چطور جریان دارد
  • چقدر طول می‌کشد تا ارزش واقعی آزاد شود
  • ریسک کجا انباشته می‌شود

این دقیقاً همان چیزی است که EBM به آن نیاز دارد.

Burndown + Cone of Uncertainty: مسکن، نه درمان

ترکیب Burndown با Cone of Uncertainty، شفافیت را بهتر می‌کند؛
اما هنوز یک فرض خطرناک را حفظ می‌کند:

«همه‌چیز باید به یک تاریخ ختم شود.»

EBM بر Outcome تأکید دارد، نه تاریخ.
Flow Metrics به‌جای سؤال «کی تمام می‌شود؟» می‌پرسند:

  • با این Throughput، با چه احتمالی تا فلان زمان این Outcome محقق می‌شود؟
  • اگر WIP را کم کنیم، Time to Market چقدر کاهش می‌یابد؟
  • کدام آیتم‌ها بیشترین Unrealized Value را دارند؟

این‌ها گفت‌وگوهای بالغ‌اند؛ Velocity‌محور نیستند.

مسیر بلوغ پیشنهادی (واقع‌بینانه، نه آرمانی)

مرحله ۱: Velocity را از «تعهد» به «سیگنال» برگردانید

  • فقط برای خود تیم
  • بدون مقایسه
  • بدون تبدیل به تاریخ

مرحله ۲: پیش‌بینی بازه‌ای و ریسک‌محور

  • استفاده از Best / Typical / Worst
  • تمرکز روی عدم‌قطعیت

مرحله ۳: ورود Flow Metrics

  • Throughput
  • Flow Time
  • WIP
  • Forecast احتمالاتی

مرحله ۴: اتصال به EBM

  • تصمیم‌گیری بر اساس Outcome
  • اولویت‌بندی بر اساس Unrealized Value
  • سرمایه‌گذاری آگاهانه، نه امیدواری

جمع‌بندی انتقادی

Velocity را می‌شود «کم‌ضررتر» کرد،
اما نمی‌شود آن را معیار اصلی تصمیم‌گیری دانست.

EBM از ما می‌خواهد:

  • از خروجی به Outcome فکر کنیم
  • از تلاش به جریان ارزش
  • از قطعیت به شواهد و احتمال

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

Velocity شاید نقطه‌ی شروع باشد،
اما Flow Metrics مقصد بلوغ‌اند.


منتورینگ رایگان مالکین محصول

«اگر در یک شرکت نرم‌افزاری مشغول به کارهای روزانه یک PO هستید و دوست دارید در مورد پیاده‌سازی اجایل، اسکرام و چالش‌های نقش PO در چهارچوب اسکرام یا تفکر استراتژیک در محصول، راهنمایی و مشاوره بگیرید، در خدمتتون هستم. یک وقت در adplist بگیرید.»


دیدگاه‌ها

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

error: اجازه کپی محتوا وجود ندارد