کیفیت کار
همانگونه که گفته شد، بهتر است روندی برای تیم پروژه وجود داشته باشد که به‌جای کار روی انبوهی از تحویل‌شدنی‌ها، روی شمار اندکی کار کرده، آن‌ها را به سرانجام برساند. بهتر است مدیر پروژه کارهای پایان یافته را بررسی و تایید نیز بکند.
تایید تحویل‌شدنی‌ها بر پایه گستره و کیفیت آن‌هاست. باید پیش از آغاز به کار روی تحویل‌شدنی‌ها از نیروهای فنی پروژه کمک بگیرید و گستره و کیفیت تحویل‌شدنی‌ها را بر پایه الزامات و نیازهای ذی‌نفعان تعیین کنید. پس از این‌که کار به پایان رسد، بر پایه همان تعریف نخستینی که به کمک اعضای تیم شده بود کارشان را بررسی خواهید کرد. این بررسی به مفهوم نظارتی از بالا به پایین و با هدف خرده‌گیری نیست، بلکه کمکی دوستانه است از سوی فردی که شاید حتی فنی هم نباشد تا با نگاهی تازه، کمی دورتر از کار به آن بنگرد و تفاوت احتمالی آن را با آنچه افراد فنی در نظر داشته‌اند بسنجد و کمبودهای احتمالی را مشخص کند.
جلوگیری از بروز دشواری‌های بنیادین در زمان تحویل نهایی، افزایش بهره‌وری کار با محدود کردن کارهای موازی، و بسیاری دیگر از عناصر مفید پروژه مستلزم تعیین گستره و کیفیت تحویل‌شدنی‌ها پیش از ساخت است. پرینس۲ برای این کار سندی به نام شرح محصول دارد («محصول» در اینجا به معنی تحویل‌شدنی است) و P3.express این مشخصات را به شکل یادداشت در نقشه تحویل‌شدنی‌ها لحاظ می‌کند. متدولوژی خود را بررسی کنید تا ببینید برای این کار چه عناصری در نظر گرفته است و اگر برای شرایط پروژه کافی نیست، آن را اضافه یا اصلاح کنید.
پروژه‌های چابک معمولا اقلام کاری را بر روی کارت‌های کوچک می‌نویسند و اطلاعات تکمیلی درباره گستره و کیفیت را در پشت کارت درج می‌کنند. تحویل‌شدنی‌های پروژه‌های نرم‌افزاری بسیار یکدست‌تر از بسیاری پروژه‌های دیگر هستند و از این رو کیفیت و سایر شرایط پذیرششان اشتراک‌های فراوانی دارند. بنابراین، بسیاری از پروژه‌های چابک به‌جای تکرار آن شرایط برای همه اقلام، اشتراک‌ها را جدا کرده، در سندی که می‌تواند definition of done نامیده شود ذخیره می‌کنند. این ترفند بسیار کارآمد است و شاید بتوانید آن را به نوعی در پروژه‌های غیرچابک نیز به کار ببرید؛ برای نمونه، شاید بتوانید بسیاری از تحویل‌شدنی‌ها را بر پایه همانندی‌های الگوی پذیرششان در چند گروه تقسیم کرده، برای هر گروه الگوی پذیرش مشترکی تدوین کنید.