هر انتشار زمان ثابت یک جلسه برنامه ریزی دارد که سازمان از آن برای هماهنگ کردن تیم ها به سوی اهداف مشترک کسب و کار استفاده می کند. چشم انداز جاری محصول (مجموعه ای از ویژگی های اولویت بندی شده) به همراه مجموعه ای از اهداف و خواسته ها، ورودی جلسه برنامه ریزی انتشار هستند.
تیم با تجزیه ویژگی ها به داستان ها و اِعمال ریتم تکرار موافقت شده و با آگاهی از سرعت خود، انتشار را برنامه ریزی می کند. تیم در طول فرایند برنامه ریزی انتشار بر روی وابستگی های داخلی خود کار می کند و داستان ها را به تکرارهای موجود در انتشار زمان ثابت تخصیص می دهد. همچنین، تیم براساس سرعت شناخته شده خود و برآوردی که برای داستان های جدید انجام داده است با مدیریت محصول در مورد محدوه سیستم مذاکره می کند تا آنچه که قابل انجام است (یا قابل انجام نیست) مشخص گردد. علاوه بر خود برنامه ریزی، نتیجه اصلی دیگر این فرایند تعهد مجموعه ای از اهداف انتشار است (به همراه مجموعه ای از ویژگی های اولویت شده). سپس، تیم تلاش می کند تعهدات خود را با دستیابی به اهداف انتشار برآورده کند.
محتویات اصلی چشم انداز، مجموعه ای از ویژگی ها هستند
چشم انداز محصول ممکن است در یک سند، در مخزن بک لاگ یا حتی در قالب اسلاید نگهداری شود. اما بدون توجه به قالب چشم انداز، محتویات اصلی آن مجموعه ای از «ویژگی های» اولویت بندی شده است که هدف آن تحویل «مزیت ها» به کاربران است.
نیازمندی های غیرکارکردی
علاوه بر این، چشم انداز محصول باید شامل نیازمندی های غیرکارکردی از قبیل قابلیت اطمینان، صحت، کارایی، کیفیت، استاندارهای سازگاری و ... باشد(سیستم برای دستیابی به اهدافش باید این نیازمندی ها را برآورده نماید).
مشابه بک لاگ محصول که حاوی «داستان ها» هستند، بک لاگ برنامه نیز حاوی «ویژگی های» اولویت بندی شده است که هنوز پیاده سازی نشده اند. ممکن است برخی از ویژگی های موجود در بک لاگ برنامه برآورد شده باشند و برخی دیگر برآورد نشده باشند. برآورد ویژگی ها در این سطح دانه درشت و نادقیق است و لذا سرمایه گذاری بیش از حدی بر روی تشریح و تخمین زود هنگام ویژگی ها انجام نمی شود.
در سازمان، مدیر محصول وظیفه نگهداری چشم انداز محصولات، سیستم ها یا برنامه کاربردی را بر عهده دارد. چشم انداز به سوالات کلان ذیل در رابطه با سیستم، برنامه کاربردی یا محصول پاسخ می دهد:
اگرچه هدف هر تکرار تولید بخش قابل عرضه از نرم افزار است، اما ممکن است تیم دریافته باشد که عرضه یک بخش از نرم افزار در هر تکرار عملی و بجا نباشد(به ویژه برای تیم های سازمانی با مقیاس بزرگ). به عنوان نمونه، تیم ممکن است دارای یکسری بدهی فنی باشد که باید قبل از عرضه محصول آن ها را برطرف نماید. بدهی فنی ممکن است شامل مواردی از قبیل نقصی که باید برطرف گردد، بازسازی ناچیز کد و انجام آزمون های کارایی، قابلیت اطمینان، سازگاری با استانداردها یا تکمیل مستندات کاربری باشد. تکرارهای تثبیت، زمان لازم برای انجام این فعالیت های اضافی را فراهم می کنند(در تصویر کلان این تکرارها در انتهای انتشار با بک لاگ خالی نمایش داده شده اند).
علاوه بر این، دلایلی برای عرضه نکردن محصول در انتهای هر تکرار وجود دارد:
به خاطر این دلایل، بیشتر برنامه ها یک سری تکرار را تحت عنوان بخش قابل عرضه از محصول تجمیع می کنند. این بخش از محصول با توجه به فضای جاری کسب وکار می تواند منتشر شود(یا منتشر نشود).