بررسی‌تان را با الزامات آغاز کنید
بیشتر افراد در پاسخ به نیازها یا مشکل‌ها بی‌درنگ نخستین راهکار «بدیهی» را انتخاب می‌کنند. اگر زمان بیشتری صرف درک مشکل و نیاز کنیم و راهکارهای گوناگون را بسنجیم، معمولا می‌توانیم گزینه‌های بهتری بیابیم. برای همین چنین روندی در همه متدولوژی‌ها وجود دارد:
الزامات ← تحویل‌شدنی‌ها ← فعالیت‌ها
گام نخست، شناسایی الزامات است؛ هم الزامات واضح و هم پنهان. بسیاری از الزامات از سوی کارفرما هستند، ولی معمولا آنچه به شما می‌گویند واقعا الزام پروژه نیست، بلکه راهکاری «بدیهی» است برای الزامی که در ذهن داشته‌اند. از این رو، باید با آن‌ها گفتگو کنید تا بتوانید الزامات واقعی را استخراج کنید. از سوی دیگر، معمولا بیش از یک نماینده از سوی کارفرما وجود دارد و الزاماتی که در اختیارتان می‌گذارند شاید با یکدیگر هماهنگ نباشند که در این حالت هم باید به شکل‌های گوناگون رفع اختلاف کنید و به مجموعه‌ای سازگار از الزامات برسید. بسته به نوع محصول پروژه و محدوده مسئولیت‌هایتان، شاید بهتر باشد به آنچه از نمایندگان کارفرما می‌شنوید نیز کاملا اعتماد نکنید و با شماری از کاربران نهایی که در آینده از محصول استفاده خواهند کرد هم گفتگو کنید.
افزون بر کارفرما، سازمان خودتان هم چه‌بسا الزاماتی برای همه پروژه‌ها داشته باشد که باید در نظرشان بگیرید. شاید آیین‌نامه‌های مختلفی هم برای نوع پروژه‌تان وجود داشته باشند که الزاماتی را حکم کنند.
همیشه باید کارتان را با درک الزامات آغاز کنید و پس از آن به سراغ تحویل‌شدنی‌ها و در پایان فعالیت‌ها بروید. پروژه‌های متعین و تطبیقی از این دیدگاه تفاوتی با هم ندارند: زمان اجرای این فرآیندها در آن‌ها یکسان نیست، ولی ترتیب فرآیندها یکسان است.
فرض کنید درگیر انجام پروژه‌ای نرم‌افزاری هستید و یکی از ذی‌نفعان به شما مراجعه می‌کند و می‌گوید که نیاز به قابلیت تازه‌ای دارند که با کمک آن نیروهای پشتیبانی سایت بتوانند بدون دانستن پسورد کاربران به‌جای آن‌ها لاگین کنند. چه خواهید کرد؟
آنچه به شما گفته‌اند درباره یک تحویل‌شدنی است، ولی می‌دانیم باید کارمان را با الزامات آغاز کنیم. پس نخستین کار این است که درباره این قابلیت با آن‌ها گفتگو کنید و درک کنید که نیاز واقعی‌شان چیست. پس از آن، به راهکارهای مختلف بیندیشید و با همکاری آن‌ها بهترین گزینه را انتخاب کنید.
روند رایج در پروژه‌های چابک این است که قابلیت‌ها در قالب user story ارائه شوند؛ برای نمونه: «به‌عنوان نیروی پشتیبانی سایت، می‌خواهم بدون در اختیار داشتن پسورد کاربران از طرف آن‌ها در سایت لاگین کنم تا وضعیت حساب و دسترسی‌هایشان را از زاویه دید خودشان ببینم و مشکل را به‌سرعت حل کنم، بدون این‌که ده‌ها پیام و تصویر از صفحه کاربر ردوبدل شود.»
این قالب بسیار مفید است، زیرا بخش پایانی آن هدف را توضیح می‌دهد و الزامی که در پس قابلیت بوده در هدف مستتر است. این قالب کمابیش مخاطب را تشویق می‌کند که به راهکارهای دیگر هم بیندیشید. افزون بر آن، به تدقیق قابلیت هم کمک می‌کند. برای نمونه، با خواندن متن بالا متوجه می‌شویم که نیازی نیست که نیروهای پشتیبانی بتوانند به‌جای مدیران سایت و سایر کاربران لاگین کنند و نیاز فقط برای مشتریان است.
آیا متدولوژیتان به اندازه کافی به الزامات پروژه اولویت می‌دهد؟ اگر این جنبه واضح یا قوی نیست، شاید بهتر باشد آن را بهبود دهید.