مقدمه؛ اسکرام یا مدیریت پروژه کلاسیک؟

یکی از بحث‌های رایج در تیم‌های پروژه این است که آیا باید پروژه را با روش‌های کلاسیک مانند WBS، برنامه زمان‌بندی، گانت چارت و کنترل پیشرفت مدیریت کرد یا به سراغ روش‌های چابک مانند Scrum رفت.

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

اما این تفاوت به این معنی نیست که یک سازمان الزاماً باید یکی را انتخاب و دیگری را کنار بگذارد.

در واقع سؤال بهتر این است:

کدام بخش پروژه به کنترل کلاسیک نیاز دارد و کدام بخش از ماهیت تکرارشونده و تطبیقی Scrum سود می‌برد؟

برای پاسخ به این سؤال، ابتدا باید تفاوت ماهوی Scrum، WBS و کنترل پروژه را بشناسیم.

WBS چیست و چه مسئله‌ای را حل می‌کند؟

WBS یا Work Breakdown Structure به معنی «ساختار شکست کار» است.

هدف WBS این است که دامنه یک پروژه بزرگ را به اجزای کوچک‌تر و قابل مدیریت تقسیم کند.

برای مثال فرض کنید پروژه‌ای برای طراحی و راه‌اندازی یک فروشگاه اینترنتی داریم. WBS پروژه می‌تواند در سطح کلان چنین ساختاری داشته باشد:

• مدیریت پروژه
• تحلیل و طراحی
• طراحی رابط کاربری
• توسعه Backend
• توسعه Frontend
• زیرساخت و استقرار
• تست و کنترل کیفیت
• آموزش
• تحویل پروژه

سپس هر کدام از این بخش‌ها به اجزای کوچک‌تری تقسیم می‌شوند.

مثلاً:

توسعه Backend

• طراحی پایگاه داده
• مدیریت کاربران
• مدیریت محصولات
• مدیریت سفارش‌ها
• پرداخت
• گزارش‌گیری

هدف اصلی WBS پاسخ دادن به این سؤال است:

برای تحویل کامل پروژه، چه چیزهایی باید تولید یا انجام شوند؟

بنابراین WBS در درجه اول ابزاری برای مدیریت دامنه و ساختاربندی پروژه است.

WBS به خودی خود نه Scrum است، نه Waterfall و نه حتی یک برنامه زمان‌بندی. بعد از ایجاد WBS می‌توان Work Packageها را به فعالیت تبدیل کرد، برای آن‌ها زمان و منابع تعیین کرد و در نهایت برنامه زمان‌بندی پروژه را ایجاد کرد.

Scrum چیست و چه مسئله‌ای را حل می‌کند؟

Scrum یک چارچوب چابک برای توسعه محصولات و حل مسائل پیچیده است.

در Scrum به‌جای اینکه فرض کنیم از روز اول تمام جزئیات محصول را می‌دانیم، یک Product Backlog ایجاد می‌شود و تیم در دوره‌های زمانی کوتاهی به نام Sprint بخشی از ارزش محصول را تولید می‌کند.

برای مثال Sprint می‌تواند دو هفته باشد.

در ابتدای Sprint تیم تعدادی از آیتم‌های Product Backlog را انتخاب می‌کند و هدف Sprint مشخص می‌شود. سپس تیم تلاش می‌کند در پایان Sprint یک Increment قابل استفاده از محصول ارائه کند.

چرخه به‌صورت ساده چنین است:

Product Backlog → Sprint Planning → Sprint → Increment → Review → Feedback → Sprint بعدی

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

• تحویل مداوم ارزش
• دریافت سریع بازخورد
• سازگاری با تغییر

این تفاوت بنیادی Scrum با برنامه‌ریزی کلاسیک است.

تفاوت اصلی Scrum و WBS در چیست؟

مقایسه مستقیم Scrum و WBS کمی گمراه‌کننده است؛ زیرا این دو دقیقاً در یک سطح قرار ندارند.

Scrum یک چارچوب مدیریت و توسعه محصول است، در حالی که WBS یک تکنیک برای تجزیه دامنه پروژه است.

به همین دلیل بهتر است Scrum را با یک سیستم مدیریت پروژه کلاسیک مقایسه کنیم که در آن WBS یکی از اجزای اصلی است.

تفاوت اصلی در واقع در فرضی است که درباره آینده پروژه داریم.

در رویکرد کلاسیک می‌گوییم:

می‌توان آینده پروژه را تا حد قابل قبولی پیش‌بینی و برنامه‌ریزی کرد.

در Scrum می‌گوییم:

آینده تا حدی نامطمئن است؛ بنابراین باید برنامه را مرتباً براساس نتایج واقعی و بازخورد اصلاح کنیم.

شباهت‌های Scrum و مدیریت پروژه کلاسیک

با وجود تفاوت‌ها، این دو رویکرد شباهت‌های مهمی نیز دارند.

۱. هر دو به دنبال کنترل پروژه هستند

گاهی تصور می‌شود Agile یعنی نداشتن برنامه.

این تصور اشتباه است.

تیم Scrum نیز دائماً برنامه‌ریزی می‌کند؛ تنها تفاوت این است که برنامه‌ریزی به‌جای یک فعالیت بزرگ در ابتدای پروژه، به‌صورت مستمر انجام می‌شود.

در Scrum حداقل در چند سطح برنامه‌ریزی داریم:

• Product Goal
• Product Backlog
• Sprint Goal
• Sprint Backlog
• برنامه روزانه تیم

بنابراین تفاوت در «وجود یا عدم وجود برنامه» نیست؛ تفاوت در افق و دفعات برنامه‌ریزی است.

۲. هر دو نیازمند تجزیه کار هستند

WBS پروژه را از سطح کلان به Work Packageها تقسیم می‌کند.

در Scrum نیز معمولاً کار از سطح‌های بزرگ‌تر به آیتم‌های کوچک‌تر تبدیل می‌شود:

Product → Epic → Feature → User Story → Task

البته Epic و Feature جزو الزامات رسمی Scrum نیستند، اما در بسیاری از تیم‌های Agile استفاده می‌شوند.

در هر دو حالت یک اصل مشترک وجود دارد:

کاری که بیش از حد بزرگ باشد، قابل تخمین، تخصیص و کنترل نیست.

۳. هر دو به تخمین نیاز دارند

در سیستم کلاسیک ممکن است یک فعالیت چنین تخمین زده شود:

توسعه ماژول پرداخت: ۸۰ نفر-ساعت

در Scrum ممکن است همان کار به چند User Story تقسیم شود و هرکدام Story Point دریافت کنند.

بنابراین تخمین در هر دو سیستم وجود دارد، اما نوع و هدف تخمین متفاوت است.

۴. هر دو نیازمند اندازه‌گیری پیشرفت هستند

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

• درصد پیشرفت
• Actual Start
• Actual Finish
• Remaining Duration
• Planned Value
• Earned Value
• Cost Variance
• Schedule Variance

Scrum نیز معیارهای دیگری دارد:

• Velocity
• Sprint Burndown
• Burnup
• Cycle Time
• Lead Time
• Throughput
• تعداد آیتم‌های Done

هر دو سیستم می‌خواهند بدانند:

پروژه در چه وضعیتی قرار دارد و با چه سرعتی به هدف نزدیک می‌شود؟

آیا می‌توان Scrum و WBS را با هم استفاده کرد؟

بله؛ و در بسیاری از پروژه‌های واقعی، این کار می‌تواند حتی از استفاده خالص از هرکدام مؤثرتر باشد.

اما شرط آن این است که مشخص کنیم هر ابزار در چه سطحی استفاده می‌شود.

یکی از بهترین مدل‌ها این است:

سطح اول: WBS برای مدیریت کلان پروژه

در این سطح موارد زیر مشخص می‌شوند:

• Deliverableهای اصلی
• فازهای پروژه
• قراردادها
• بودجه
• نقاط عطف
• تعهدات مشتری
• وابستگی بین بخش‌ها

مثلاً:

1. تحلیل

2. طراحی

3. توسعه محصول

4. زیرساخت

5. آموزش

6. استقرار

در این ساختار «توسعه محصول» می‌تواند یک Work Package بزرگ باشد.

اما لازم نیست صدها فعالیت توسعه نرم‌افزار از همان روز اول در برنامه زمان‌بندی پروژه تعریف شوند.

سطح دوم: Scrum برای مدیریت اجرای Work Packageها

فرض کنیم در WBS یک بسته کاری داریم:

3.2 توسعه سیستم مدیریت سفارش

به‌جای شکستن این Work Package به ۸۰ فعالیت کوچک در Primavera یا Microsoft Project، می‌توان آن را به یک Product Backlog مرتبط کرد.

Product Backlog ممکن است شامل این موارد باشد:

• ایجاد سفارش
• ویرایش سفارش
• لغو سفارش
• پرداخت سفارش
• مشاهده وضعیت سفارش
• ارسال پیامک
• بازپرداخت
• گزارش سفارش‌ها

تیم توسعه این Backlog را طی چند Sprint انجام می‌دهد.

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

Project

این ساختار یکی از کاربردی‌ترین روش‌های ترکیب کنترل پروژه کلاسیک و Agile است.

مثال عملی از ترکیب WBS و Scrum

فرض کنید پروژه طراحی یک نرم‌افزار سازمانی ۱۲ ماه زمان دارد.

WBS سطح بالا چنین است:

۱. تحلیل و طراحی

مدت هدف: ۲ ماه

۲. توسعه نرم‌افزار

مدت هدف: ۷ ماه

۳. زیرساخت

مدت هدف: ۳ ماه

۴. مهاجرت داده

مدت هدف: ۲ ماه

۵. آموزش

مدت هدف: ۱ ماه

۶. استقرار نهایی

مدت هدف: ۱ ماه

بعضی از این فعالیت‌ها هم‌پوشانی دارند.

در برنامه کنترل پروژه، مدیر پروژه می‌تواند این ساختار را به‌صورت یک Master Schedule مدیریت کند.

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

فرض کنیم Sprint دو هفته‌ای باشد.

۷ ماه توسعه تقریباً شامل ۱۴ تا ۱۵ Sprint خواهد شد.

کنترل پروژه تنها نقاط مهم را مشاهده می‌کند:

• شروع توسعه
• نسخه Alpha
• نسخه Beta
• UAT
• Release Candidate
• Production Release

در حالی که Scrum جزئیات داخل این فاصله‌ها را مدیریت می‌کند.

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

ارتباط Milestoneهای کلاسیک با Sprintها

یکی از بهترین نقاط اتصال دو سیستم، Milestone است.

فرض کنید در برنامه اصلی پروژه داریم:

Milestone: آماده‌شدن نسخه Beta تا ۳۰ آبان

تیم Scrum می‌تواند Sprintهای خود را به‌گونه‌ای برنامه‌ریزی کند که Product Goal مرتبط با Beta در حدود این تاریخ تحقق پیدا کند.

بنابراین لازم نیست مدیر پروژه تک‌تک User Storyها را وارد برنامه اصلی کند.

مدیر پروژه می‌بیند:

Beta Release — 30 Aban

ولی تیم Scrum می‌بیند:

• Sprint 7
• Sprint 8
• Sprint 9
• Sprint 10
• Product Backlog
• Sprint Goals

این تفکیک باعث می‌شود برنامه اصلی پروژه بیش از حد پیچیده نشود.

آیا Sprint باید وارد WBS شود؟

معمولاً بهتر است Sprint را مستقیماً به‌عنوان ساختار اصلی WBS تعریف نکنیم.

مثلاً چنین WBSای:

• Sprint 1
• Sprint 2
• Sprint 3
• Sprint 4
• Sprint 5

ساختار مناسبی برای WBS نیست؛ زیرا WBS بهتر است Deliverable-oriented باشد.

ساختار بهتر:

3. توسعه

• 3.1 مدیریت کاربران
• 3.2 مدیریت مشتریان
• 3.3 مدیریت سفارش
• 3.4 پرداخت
• 3.5 گزارش‌گیری

و هرکدام از این موارد می‌توانند طی چند Sprint توسعه پیدا کنند.

Sprint یک Timebox است؛ WBS یک ساختار دامنه و تحویل‌دادنی‌ها است.

این دو نباید با هم اشتباه گرفته شوند.

یکی از بزرگ‌ترین مشکلات مدل ترکیبی: درصد پیشرفت

اینجا یکی از چالش‌های جدی ظاهر می‌شود.

فرض کنید مدیر پروژه سؤال می‌کند:

توسعه نرم‌افزار چند درصد پیشرفت کرده است؟

تیم Scrum ممکن است پاسخ دهد:

چنین درصدی چندان معنادار نیست؛ ما در Sprint چهارم هستیم و Velocity فعلی ۴۵ Story Point است.

مدیر پروژه اما برای گزارش مدیریتی به یک عدد نیاز دارد.

راه‌حل، ایجاد یک لایه تبدیل اطلاعات است.

مثلاً برای هر Work Package وزن تعیین کنیم.

با تکمیل واقعی Deliverableها می‌توان پیشرفت Work Package را محاسبه کرد.

در این مدل بهتر است از معیارهایی مثل «تعداد تسک بازشده» یا «مدت زمان سپری‌شده» برای اعلام پیشرفت استفاده نکنیم.

پیشرفت زمانی واقعی است که خروجی قابل تحویل تولید شده باشد.

Story Point را با نفر-ساعت اشتباه نگیریم

یکی از اشتباهات متداول در ترکیب Scrum و کنترل پروژه این است که مدیر پروژه تلاش می‌کند Story Point را مستقیماً به ساعت تبدیل کند.

مثلاً:

هر Story Point برابر با ۶ ساعت است.

این تبدیل معمولاً فلسفه Story Point را از بین می‌برد.

Story Point یک معیار نسبی است که ترکیبی از پیچیدگی، حجم کار و عدم قطعیت را منعکس می‌کند.

اما مدیر پروژه ممکن است برای برنامه‌ریزی منابع به ساعت نیاز داشته باشد.

در چنین شرایطی بهتر است دو سیستم جدا بمانند:

مدیر پروژه می‌تواند از Velocity برای Forecast استفاده کند بدون اینکه Story Point را به ساعت تبدیل کند.

چه پروژه‌هایی برای مدل ترکیبی مناسب‌اند؟

مدل Hybrid به‌خصوص در پروژه‌هایی مفید است که بخشی از پروژه قابل پیش‌بینی و بخشی نامطمئن است.

نمونه‌های رایج:

• پروژه‌های ERP
• توسعه نرم‌افزار سازمانی
• بانکداری
• فین‌تک
• مخابرات
• پروژه‌های تحول دیجیتال
• طراحی محصولات پیچیده
• پروژه‌هایی با چند پیمانکار
• پروژه‌های دولتی
• پروژه‌هایی که قرارداد و زمان تحویل مشخص دارند

فرض کنید پروژه راه‌اندازی یک سامانه بانکی دارید.

خرید سرور، آماده‌سازی دیتاسنتر، قراردادها و مهاجرت زیرساخت معمولاً قابلیت برنامه‌ریزی کلاسیک بیشتری دارند.

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

استفاده از یک روش واحد برای همه این کارها الزاماً بهترین تصمیم نیست.

چه زمانی استفاده خالص از Scrum مناسب‌تر است؟

اگر تیم روی یک Product مستمر کار می‌کند و پروژه پایان مشخص قراردادی ندارد، احتمالاً WBS کلاسیک ارزش کمتری ایجاد می‌کند.

مثلاً یک شرکت SaaS ممکن است محصول خود را سال‌ها توسعه دهد.

در چنین محیطی:

• Product Roadmap
• Product Goal
• Backlog
• Sprint
• Release Planning

ممکن است برای مدیریت کار کافی باشند.

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

چه زمانی روش کلاسیک مناسب‌تر است؟

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

برای مثال نمی‌توان قبل از اجرای فونداسیون، اسکلت را اجرا کرد.

در چنین پروژه‌ای:

• CPM
• Critical Path
• WBS
• Resource Planning
• Cost Control
• Earned Value

نقش بسیار پررنگ‌تری دارند.

البته حتی در همین پروژه‌ها نیز برخی بخش‌ها مانند طراحی مهندسی یا توسعه نرم‌افزارهای جانبی می‌توانند Agile اجرا شوند.

۵ اشتباه رایج در ترکیب Scrum و WBS

۱. ایجاد دو سیستم موازی برای یک کار

اگر یک Developer مجبور باشد یک کار را هم در Backlog و هم در نرم‌افزار کنترل پروژه ثبت و روزانه هر دو را به‌روزرسانی کند، سیستم Hybrid به یک سیستم بوروکراتیک تبدیل می‌شود.

اصل بهتر:

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

۲. وارد کردن همه Taskهای Scrum به برنامه اصلی

برنامه اصلی پروژه باید قابل مدیریت باقی بماند.

اگر هزاران Task داخلی تیم وارد Master Schedule شوند، کنترل پروژه عملاً غیرممکن می‌شود.

بهتر است اتصال دو سیستم در سطح مواردی مانند این‌ها انجام شود:

• Deliverable
• Epic
• Release
• Milestone
• Work Package

۳. تثبیت بیش از حد Backlog

اگر تمام Backlog یک پروژه ۱۲ ماهه از روز اول به‌عنوان Baseline غیرقابل تغییر اعلام شود، عملاً بخش مهمی از مزیت Agile را از بین برده‌ایم.

جزئیات Backlog باید امکان Refinement داشته باشند.

۴. حذف کامل تعهد زمانی با نام Agile

از سوی دیگر Agile به معنی این نیست که هیچ تاریخ، بودجه یا تعهدی وجود نداشته باشد.

یک سازمان ممکن است نیاز داشته باشد:

• تا پایان فصل نسخه جدید منتشر کند؛
• در سقف بودجه مشخصی باقی بماند؛
• در تاریخ مشخصی محصول را به مشتری تحویل دهد.

Scrum می‌تواند داخل این محدودیت‌ها اجرا شود.

۵. اندازه‌گیری افراد به‌جای جریان کار

Velocity یا تعداد Taskهای تکمیل‌شده نباید به ابزاری برای مقایسه مستقیم افراد تبدیل شود.

تمرکز بهتر روی معیارهای سیستمی است:

• Throughput
• Cycle Time
• Lead Time
• Delivery Reliability
• تعداد آیتم‌های تکمیل‌شده
• میزان تحقق Sprint Goal

یک معماری پیشنهادی برای پروژه Hybrid

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

لایه ۱: Portfolio

پروژه‌ها و اولویت‌های کلان سازمان.

لایه ۲: Project

بودجه، قرارداد، تاریخ‌های کلیدی و اهداف پروژه.

لایه ۳: WBS

Deliverableها و Work Packageهای اصلی.

لایه ۴: Product / Epic

قابلیت‌های عمده محصول.

لایه ۵: Product Backlog

User Storyها و نیازمندی‌های قابل اولویت‌بندی.

لایه ۶: Sprint

تعهد کوتاه‌مدت تیم.

لایه ۷: Task

اقدامات اجرایی روزانه.

این مدل باعث می‌شود مدیرعامل، مدیر پروژه، Product Owner و Developer هرکدام اطلاعات را در سطحی ببینند که برای تصمیم‌گیری آن‌ها مفید است.

نقش ابزار مدیریت پروژه در اجرای چنین مدلی

در یک سیستم Hybrid، ابزار مدیریت پروژه باید بتواند بین «مدیریت کار روزمره» و «تصویر مدیریتی پروژه» ارتباط ایجاد کند.

برای مثال وجود امکاناتی مانند:

• پروژه
• برد
• تسک
• مسئول انجام
• تاریخ سررسید
• اولویت
• وزن کار
• زمان تخمینی
• تایم‌لاگ
• گزارش عملکرد
• فیلتر براساس پروژه و اعضا

می‌تواند اطلاعات اجرایی را به گزارش‌های مدیریتی متصل کند.

در تیک‌بورد نیز تسک‌ها می‌توانند به پروژه متصل شوند و برای هر کار مسئول، سررسید، اولویت، وزن، زمان تقریبی، Checklist، ثبت زمان و تاریخچه تغییرات نگهداری شود. همچنین گزارش‌ها امکان بررسی کارها براساس پروژه، برد، مسئول، تاریخ و وضعیت را فراهم می‌کنند.

تیک‌بورد در ساختار فعلی خود همچنین از Board، Task، ثبت زمان، گزارش عملکرد و پروژه‌های مرتبط با مشتری پشتیبانی می‌کند؛ بنابراین چنین ابزارهایی می‌توانند لایه اجرای مدل Hybrid را پوشش دهند، حتی اگر سازمان در سطح بالاتر از WBS یا Master Schedule نیز استفاده کند.

Scrum جای کنترل پروژه را می‌گیرد؟

نه کاملاً.

Scrum بخش مهمی از کنترل عملیات تیم توسعه را انجام می‌دهد، اما مسائلی مانند این‌ها لزوماً مسئله اصلی Scrum نیستند:

• کنترل کل بودجه پروژه
• قرارداد پیمانکاران
• Cash Flow
• مدیریت چند پروژه
• Critical Path کل پروژه
• برنامه پرداخت
• Procurement
• کنترل تغییرات قراردادی
• مدیریت تعهدات چند پیمانکار

در پروژه‌های بزرگ همچنان ممکن است به ساختار Project Management Office یا Project Controls نیاز داشته باشیم.

از طرف دیگر کنترل پروژه نیز جای Product Management و Scrum را نمی‌گیرد.

یک برنامه زمان‌بندی ۳۰۰۰ فعالیتی نمی‌تواند مشخص کند مشتری واقعاً چه محصولی می‌خواهد.

پس بالاخره Scrum بهتر است یا WBS؟

این سؤال تقریباً شبیه این است که بپرسیم:

نقشه بهتر است یا قطب‌نما؟

هرکدام مسئله متفاوتی را حل می‌کنند.

WBS به شما کمک می‌کند بفهمید:

کل پروژه شامل چه چیزهایی است؟

برنامه کنترل پروژه کمک می‌کند بفهمید:

چه چیزی چه زمانی باید اتفاق بیفتد و الان نسبت به برنامه کجا هستیم؟

Scrum کمک می‌کند بفهمید:

در شرایطی که همه جزئیات را نمی‌دانیم، چگونه مرحله‌به‌مرحله بهترین محصول ممکن را بسازیم؟

بهترین سازمان‌ها الزاماً طرفدار یک مکتب خاص نیستند؛ بلکه ابزار را متناسب با مسئله انتخاب می‌کنند.

جمع‌بندی

Scrum و مدیریت پروژه کلاسیک مبتنی بر WBS دو روش کاملاً متضاد نیستند.

WBS ابزار قدرتمندی برای مشخص کردن ساختار دامنه، Deliverableها و Work Packageهای پروژه است. کنترل پروژه کلاسیک نیز برای مدیریت زمان، هزینه، منابع، تعهدات و Milestoneهای کلان ارزش زیادی دارد.

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

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

WBS برای ساختار کلان پروژه

↓

Work Package برای تعیین مسئولیت و تحویل‌دادنی‌ها

↓

Backlog برای مدیریت نیازمندی‌های قابل تغییر

↓

Sprint برای برنامه‌ریزی کوتاه‌مدت

↓

Task برای اجرای روزانه

در چنین مدلی مدیریت ارشد همچنان بودجه، Milestone، دامنه و وضعیت کل پروژه را کنترل می‌کند؛ در حالی که تیم اجرایی مجبور نیست تمام جزئیات چند ماه آینده را از روز اول پیش‌بینی کند.

بنابراین پاسخ کوتاه به سؤال اصلی این است:

بله، Scrum و WBS نه‌تنها قابل استفاده در کنار یکدیگر هستند، بلکه در پروژه‌های پیچیده، ترکیب درست آن‌ها می‌تواند واقع‌بینانه‌تر و مؤثرتر از اصرار بر استفاده خالص از یکی از دو رویکرد باشد.

نکته کلیدی این است که WBS و کنترل پروژه را در سطح مدیریت کلان نگه داریم و Scrum را به‌عنوان موتور اجرای تطبیقی پروژه به کار ببریم؛ نه اینکه دو سیستم موازی و تکراری برای مدیریت همان کارها ایجاد کنیم.