آموزش اسکرام، قسمت ششم: مصنوعات اسکرام

واژه‌ی مصنوع / مصنوعات، به‌معنی چیزی است که انسان ساخته‌ است؛ اما مصنوعات اسکرام صرفا اسناد یا ابزارهایی هستند که با بهره‌گیری از آن‌ها، مشکلاتمان را حل می‌کنیم. مصنوعات اسکرام برخی از اطلاعات مهم را درباره‌ی «نحوه‌ی توسعه‌ی محصول» و «فعالیت‌های انجام‌شده» و «فعالیت‌های برنامه‌ریزی‌شده» دراختیار تیم اسکرام و ذی‌نفعان پروژه قرار می‌دهد. در بخش گذشته، گفتیم بک‌لاگ محصول و بک‌لاگ اسپرینت و Increment محصول، مهم‌ترین مصنوعات اسکرام هستند. برخی دیگر از مصنوعات نیز عبارت‌اند از:

• چشم‌انداز محصول
• هدف اسپرینت
• تعریف Done
• نمودار Burn-Up
• نمودار Burn-Down

 پیش از آغاز مباحث مهمی که درباره‌ی مصنوعات اسکرام مطرح می‌شود، بیایید نگاهی اجمالی به سه گزینه‌ی اصلی بیندازیم: 

بک‌لاگ محصول (The Product Backlog): بک‌لاگ محصول فهرستی از ویژگی‌های اولویت‌بندی‌شده است که باید در محصول نهایی لحاظ شود. این فهرست درحقیقت منبع اصلی الزاماتی است که در محصول اعمال می‌شود. بک‌لاگ محصول به‌عنوان یکی از مصنوعات کاملا مشهود در قلب چهارچوب اسکرام، در همه‌ی پروژه‌ها دردسترس است.

بک‌لاگ اسپرینت (The Sprint Backlog): بک‌لاگ اسپرینت فهرستی از کارهایی است که تیم باید در پایان هر اسپرینت تکمیل کرده باشد. در طول جلسه‌ی برنامه‌ریزی اسپرینت، تیم اسکرام آیتم‌های اولویت‌داری را انتخاب می‌کند که مالک محصول از فهرست بک‌لاگ محصول تعیین‌ کرده است. این آیتم‌ها معمولا در قالب داستان‌های کاربر بیان می‌شوند. بک‌لاگ اسپرینت فرایند‌ی برنامه‌ریزی‌شده و حاوی اطلاعات کاملی است که کمک می‌کند در طول جلسات اسکرام روزانه، تغییرات اعمال‌شده در «توسعه» را کاملا درک کنید. در طول هر اسپرینت، تیم توسعه این آیتم‌های بک‌لاگ اسپرینت را تعدیل می‌کند.

اینکریمنت (Increment) محصول: واژه‌ی Increment به‌معنای افزایش و ارتقا، به مفهوم رسیدن به سطح بعدی است. درواقع، اینکریمنت قدمی به‌سمت هدف یا چشم‌انداز است. تعدادی از آیتم‌های بک‌لاگ محصول که در طول اسپرینت جاری و نیز اسپرینت‌های قبلی تکمیل‌ شده‌اند، بخش افزایشی یا اینکریمنت محصول را شکل می‌دهند. در پایان هر اسپرینت، تیم اسکرام باید هر آیتم بک‌لاگ محصول را طبق فرم بازبینی تصویب‌شده‌ی «تعریف Done» تکمیل کرده باشد.

بک‌لاگ محصول فهرستی از ویژگی‌ها، الزام‌ها، توابع، پیشرفت‌ها و اصلاحاتی است که به تغییراتی منجر می‌شود که باید در پخش بعدی محصول اعمال شود. آیتم‌های بک‌لاگ محصول از مشخصه‌هایی مانند توصیف، برآورد، ارزش و ترتیب برخوردار هستند. این آیتم‌های بک‌لاگ به‌عنوان داستان یا استوری کاربر شناخته می‌شوند. البته از داستان‌های کاربر با عنوان موارد استفاده (Use Cases) نیز یاد می‌شود. صاحب محصول (PO) مسئولیت اولویت‌بندی را به‌عهده دارد. او باید اولویت الزامات را براساس ارزش بازار و بازخورد مشتریان تعیین کند.

• سند فعال و مهمی که فهرست همه‌ی «خواسته‌های کاربران» را شامل می‌شود.
• مالک محصول اطمینان می‌دهد محتویات بک‌لاگ محصول، یعنی «داستان‌های کاربر»، دقیق و واضح تعریف می‌شوند.
• داستان‌های کاربر باید از اندازه‌ی خاص و ثابتی برخوردار باشند تا بتوانند در هر اسپرینت اجرا شوند.
• هر داستان کاربر، باید از معیارهای پذیرش مناسب و سناریوهایی درزمینه‌ی موارد استفاده برخوردار باشد.
• آیتم‌های بک‌لاگ محصول توضیحات آزمونی را شامل می‌شوند که ثابت می‌کند تعریف Done محقق شده است.
• بک‌لاگ محصول به‌لحاظ عملیاتی ورودی بک‌لاگ اسپرینت محسوب می‌شود.
• بک‌لاگ محصول مبتنی‌بر ماهیت داستان کاربر مشخص می‌کند در مرحله‌ی بعد، چه‌ کاری باید انجام شود.

مال محصول مسئول ایجاد بک‌لاگ محصول و نگه‌داری از آن است. او فهرست آیتم‌های موجود در بک‌لاگ را براساس اولویت‌ها مجددا مرتب می‌کند. ممکن است اعضای تیم یا افراد دیگر پیشنهاد دهند Featureها یا ویژگی‌های دیگری نیز به فهرست بک‌لاگ محصول اضافه شود؛ ولی این مالک محصول است که تصمیم نهایی را اتخاذ می‌کند.

بک‌لاگ محصول شامل تمام داستان‌های کاربر با آیتم‌هایی است که ازنظر عملکرد اولویت فراوانی دارند. مالک محصول داده‌های لازم برای ساخت محصول را از ذی‌نفعان جمع‌آوری می‌کند. سپس، داستان‌های کاربر را به‌منظور دستیابی به اهداف آماده می‌کند. در این مرحله، مالک محصول روی شناخت و تعریف نیازهای کاربر متمرکز می‌شود.

داستان کاربر بهترین راه برای بیان نیازهای مشتریان پروژه است. اگر از ساختار زیر استفاده کنیم، ایجاد داستان کاربر اصلا کار سختی نیست:

من به‌عنوان یک «...» به «...» نیاز دارم یا آن را می‌خواهم.

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

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

۱. خودتان را به‌عنوان مشتری ببینید تا نیازهای کاربر را درک کنید.

۲. کار را ساده شروع کنید. هر چیزی را که به‌عنوان ورودی به ذهنتان می‌رسد، یادداشت کنید.

۳. همه‌ی افرادی را که کاربرهای متمایز محسوب می‌شوند، شناسایی کنید؛ مانند کارکنان، مدیران، شرکا و ذی‌نفعان.

۴. برای هر داستان کاربر، ارزش کسب‌وکار در نظر بگیرید تا اهمیت آن را ازنظر سازمان درک کنید.

۵. هر زمان که به الزامات جدیدی پی بردید، اولویت‌ها را اصلاح کنید.

۶. مداوم به بک‌لاگ محصول بازگردید تا عملیات پاک‌سازی را در آن انجام دهید (اضافه‌کردن و حذف‌کردن و اولویت‌بندی مجدد).

آیتم‌های بک‌لاگ محصول به‌صورت خطی و براساس معیارهای DIVE اولویت‌بندی می‌شوند. معیارهای DIVE عبارت‌اند از:

• وابستگی‌ها
• اطمینان دربرابر علل ریسک
• ارزش کسب‌وکار
• میزان تلاش پیش‌بینی‌شده
• جزئیات مقتضی و مناسب
• برآوردها
• اقلام و شرایط نوظهور
• ویژگی‌های مهم داستان‌های کاربر (مستقل‌بودن، مذاکره‌‌شدنی‌بودن، ارزشمندبودن، تخمین‌پذیر بودن، آزمودنی‌بودن)

در قسمت گذشته، گفتیم پاک‌سازی بک‌لاگ محصول (Grooming/Product Backlog Refinement) روشی برای منظم و تمیز و به‌روز نگه‌داشتن بک‌لاگ محصول است. جلسه‌ی PBR در پایان هر اسپرینت و به‌صورت بحثی مشترک میان اعضای تیم برگزار می‌شود.

مزیت پاک‌سازی بک‌لاگ این است که کمک می‌کند زمان زیادی در جلسه‌ی برنامه‌ریزی اسپرینت صرفه‌جویی کنیم. اگر آیتم‌های بک‌لاگ به‌وضوح و براساس معیارهای مصوب مشخص‌شده باشد و به‌طور مناسب اعضای تیم آن را بررسی کنند، فرایند برنامه‌ریزی پیش از آغاز جلسه تکمیل می‌شود. همچنین، PBR به اعضای تیم اجازه می‌دهد درباره‌ی داستان‌های کاربر با یکدیگر تعامل داشته باشند.

در اینجا، سؤال مهم این است: در چه زمانی از اسپرینت، عملیات پاک‌سازی بک‌لاگ را انجام می‌دهیم؟ باید پاک‌سازی بک‌لاگ را فرایند‌ی مداوم بدانیم. بااین‌حال، برخی از تیم‌ها نیز ترجیح می‌دهند در اواسط اسپرینت، جلسه‌ی برنامه‌ریزی برگزار کنند و درباره‌ی آیتم‌های بک‌لاگ اسپرینت آتی، به گفت‌وگو بنشینند. پس از نهایی‌شدن نتایج این جلسه، پاک‌سازی و اصلاح بک‌لاگ آغاز می‌شود.

جلسه‌ی اصلاح بک‌لاگ محصول با حضور اسکرام‌مستر برگزار می‌شود. اسکرام‌مستر همه‌چیز را برای اعضای تیم و نیز مالک محصول آماده می‌کند. آن‌ها آیتم‌های بالایی بک‌لاگ محصول را بررسی می‌کنند. اگر تیم به مسئله‌ی حل‌نشده‌ای برخورد کند، می‌تواند آن را در جلسه‌ی برنامه‌ریزی اسپرینت مطرح کند.

نکته‌ی مهم: سعی نکنید جلسه‌ی PBR را برای ۲۰ درصد ابتدایی یا انتهایی اسپرینت برنامه‌ریزی کنید.

هدف جلسه‌ی PBR این است که آیتم‌های بک‌لاگ محصول را به حالت Ready درآوریم. تیم توسعه درصورت زیر آیتم‌های بک‌لاگ را آماده (Ready) می‌داند:

• به‌اندازه‌ی کافی واضح باشند: تیم توسعه باید خواسته‌های ذی‌نفعان را عمیقا درک کند و بداند چرا آن‌ها چنین خواسته‌هایی دارند.
• به‌اندازه‌ی کافی کوچک باشند: آیتم‌های بک‌لاگ باید به‌اندازه‌ی خرد باشند که بتوان آن‌ها را در هر اسپرینت طبق تعریف Done تکمیل کرد.

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

نکته‌ی ۱: برای اینکه جلسه‌ی پاک‌سازی بک‌لاگ موفقی داشته باشید، نباید درباره‌ی همه‌چیز بحث کنید!

نکته‌ی ۲: گفتیم فرایند برنامه‌ریزی ممکن است قبل از برگزاری جلسه انجام شود. این اتفاق زمانی رخ می‌دهد که آیتم‌های بک‌لاگ به‌وضوح در معیارهای مصوب ذکر شده باشند و بررسی متقابل بین اعضای تیم صورت گرفته باشد.

پس از جلسه‌ی PBR، تیم می‌تواند آیتم‌های بک‌لاگ را به‌روزرسانی کند. درنهایت، Potentially Shippable Product خواهید داشت که آماده‌ی عرضه به بازار است.

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

در تصویر زیر، مشاهده می‌کنید که الزامات چگونه در بک‌لاگ اسپرینت اولویت‌بندی می‌شوند.

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

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

۱. بک‌لاگ اسپرینت از ماهیتی پویا برخوردار است؛ زیرا در هر اسپرینت، تغییرات مکرری برای دستیابی به اهداف به‌وجود می‌آید. بااین‌حال، فرایند‌ خوب هم روی اهداف متمرکز می‌ماند و هم بک‌لاگ اسپرینت را تاحدممکن ثابت نگه می‌دارد.

۲. بک‌لاگ اسپرینت یکی از خروجی‌های جلسه‌ی برنامه‌ریزی اسپرینت است.

۳. بک‌لاگ اسپرینت به تیم توسعه کمک می‌کند «کارهای ضروری» برای رسیدن به اهداف اسپرینت را شناسایی کنند.

۴. در جلسه‌ی برنامه‌ریزی، تیم توسعه درباره‌ی تقسیم‌کردن آیتم‌های انتخابی و تبدیل آن‌ها به وظایف کوچک‌تر و نیز برآورد آن‌ها تصمیم‌گیری می‌کند.

۵. تیم توسعه مالک و مسئول بک‌لاگ اسپرینت است.

۶. پیش از شروع هر اسپرینت، تیم توسعه سند برنامه‌ریزی را براساس الزامات و اولویت «ارزش بازار» در بک‌لاگ اسپرینت ایجاد می‌کند.

در مرحله‌ی اول، تیم توسعه آیتم‌هایی (PBI) را که دوست دارد روی آن‌ها کار کند، از فهرست بک‌لاگ محصول انتخاب و به فهرست بک‌لاگ اسپرینت اضافه می‌کند. سپس، PBIها را به بخش‌های کوچک‌تر (Taskهای اسپرینت) تقسیم می‌کند تا کارکردن روی آن‌ها آسان‌تر شود. یکی از بهترین روش‌های اجرایی، این است که بک‌لاگ اسپرینت را با استفاده از کارت‌های شاخص یا کاغذ یادداشت‌های چسبنده روی تخته یا بورد وظایف نمایش دهیم. البته، همه‌ی این فرایندها به‌صورت الکترونیکی روی بورد دیجیتال نیز انجام می‌شود. در تصویر زیر، ساختار بورد وظایف را مشاهده می‌کنید.

• مطمئن شوید همه‌ی اعضای تیم در این فرایند حضور دارند.
• انواع وظایف را شناسایی کنید.
• تعریف Done را شخص کنید.
• درباره‌ی نحوه‌ی اجرای هر آیتم بحث کنید.
• وظایف را پیشاپیش به کسی واگذار کنید.
• تعهدات اسپرینت را تعیین کنید.
• بک‌لاگ اسپرینت را در طول دوره‌ی اسپرینت توسعه دهید.
• زمان زیادی را صرف این فرایند نکنید.

پیش از نهایی‌کردن بک‌لاگ اسپرینت، عبارات عمومی زیر را تحلیل و درصورت نیاز، تغییرات لازم را در بک‌لاگ اعمال کنید:

بررسی موانع: آیا می‌توان داستان‌های موجود در بک‌لاگ اسپرینت را در بازه‌ی اسپرینت تکمیل کرد؟

تعریف Done: مطمئن شوید همه‌ی عوامل مرتبط با تعریف تیم از Done را در نظر گرفته‌اید.

آیتم‌های فراموش‌شده: آیا ممکن است کارهای واقعا ضروری را به فهرست بک‌لاگ اسپرینت وارد نکرده باشید؟ اگر پاسخ مثبت است، آن‌ها را برآورد و به بک‌لاگ اضافه کنید. آیتم‌ها را به‌شیوه‌ای تنظیم کنید که در زمان توافق‌شده‌ی تیم به‌پایان برسند.

تعهد: آیا می‌توانید به برنامه‌ی اسپرینت متعهد بمانید؟ آیا می‌توانید توضیح دهید چگونه می‌خواهید اسپرینت را تحویل دهید؟

تنظیم بورد وظایف: آیا برنامه‌ی اسپرینت در یکی از ابزارهای چابک یا تخته‌ی وظایف به‌طور کامل شرح داده‌ شده است؟ چگونه ردیابی اسپرینت را آغاز می‌کنید؟

ریسک‌ها: آیا در طول اسپرینت باید از برخی ریسک‌ها آگاه باشید؟

در طول هر اسپرینت، اعضای تیم اسکرام به‌ترتیب و از بالا داستان‌های کاربر را از بک‌لاگ اسپرینت برمی‌دارند. این داستان‌ها از تایم‌باکسی برخوردار هستند که براساس سرعت متوسط تیم تنظیم‌ شده است. به هریک از داستان‌ها، براساس میزان تلاش لازم برآوردشده، وزنی اختصاص داده می‌شود. وزن داستان ارزش نقطه‌ای (Point Value) نام دارد. به‌یاد داشته باشید تیم اسکرام داستان‌ها را برمبنای Pointها برآورد می‌کند، نه برمبنای ساعت. سپس، تیم درباره‌ی بهترین راه تکمیل کارهای بک‌لاگ اسپرینت تصمیم‌گیری می‌کند. البته، ممکن است تیم کارهای با اولویت بالا را زودتر انجام دهد.

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

درحالی‌که تیم توسعه تصمیم می‌گیرد چه‌ کارهایی برای هر داستان کاربر انجام دهد، پاسخ به پرسش‌های زیر نیز در طول فرایند برنامه‌ریزی به تیم ما کمک می‌کند:

• آیتم بعدی که از بیشترین اولویت برخوردار است و باید در این اسپرینت تحویل داده شود، چیست؟ برای کار روی این آیتم برنامه‌ریزی می‌کنیم.
• چه چیز دیگری باید درباره‌ی این داستان کاربر بدانیم؟ آیا خروجی‌ها روشن هستند؟ آیا معیارهای پذیرش به‌طورکامل الزامات داستان‌های کاربر را شرح می‌دهد؟
• استراتژی ما برای تحویل به‌موقع این داستان کاربر چیست؟
• آیا رویکردی برای اجرای داستان می‌شناسیم؟
• چه تلاشی برای کارهای موردنیاز تکمیل داستان کاربر تخمین می‌زنیم؟
• آیا تمام‌ کارهای لازم برای انجام (Done) داستان را بررسی کرده‌ایم؟
• آیا مشغول برنامه‌ریزی برای انجام همین کار هستیم؟ آیا همه‌چیز را به‌درستی ارزیابی می‌کنیم؟

بخش افزایشی محصول (PI) مجموعه آیتم‌های کلی به‌پایان‌رسیده در طول هر اسپرینت و همچنین اسپرینت‌های تکمیل‌شده‌ی قبلی است. در پایان هر اسپرینت، باید محصولی کاربردی ارائه شود که بتوان آن را به خطِ‌تولید رساند. این بدان معنی است که در انتهای هر اسپرینت، باید محصول کارآمد و کاربردی داشته باشیم که با تعریف Done مطابقت داشته باشد. صرف‌نظر از اینکه مالک محصول چه تصمیمی می‌گیرد، PI محصول کاربردی است. مهم‌ترین گزینه از مصنوعاتی که در چهارچوب اسکرام ایجاد می‌شود، محصول افزایشی واقعی است.

یکی از وظایف تیم اسکرام این است که تصمیم بگیرد چه چیزی به‌عنوان PI در نظر بگیرد. شاید تیم‌های مختلف اسکرام تصمیمات بسیار متفاوتی درزمینه‌ی PI اتخاذ کنند؛ ولی درهرحال اعضای تیم باید بتوانند کارهایی را به‌اشتراک بگذارند که تکمیل می‌کنند. در جلسه‌ی برنامه‌ریزی اسپرینت، همین دانش به‌اشتراک‌گذاری است که شما را در انتخاب آیتم‌های بک‌لاگ محصول هدایت می‌کند. پس، تیم توسعه مسئولیت محصول را برعهده دارد و هدف هر اسپرینت، ارائه‌ی محصول نرم‌افزاری کاربردی است.

هدف فرایند اسکرام این است که کیفیت محصول در پایان هر دوره‌ی تکرار، با تعریف Done مطابقت داشته و محصول نیز عرضه‌شدنی باشد. این محصول به‌منظور دریافت بازخورد اولیه دراختیار مشتریان یا ذی‌نفعان قرار می‌گیرد و همچنین، به‌عنوان ابزاری برای آزمایش استفاده می‌شود. گرچه سازمان‌ها الزاما در پایان هر اسپرینت باید Shippable Product را طبق برنامه‌ی فرایند اسکرام تحویل دهند، همین امر محصول را به بخشی از روند مداوم توسعه، ارزیابی، آزمون و نوآوری تبدیل می‌کند.

در طول هر اسپرینت، تمام فعالیت‌های ضروری مانند تجزیه‌وتحلیل، طراحی، ساخت، ادغام و آزمایش را تیم اسکرام انجام می‌دهد تا PI قابل‌استفاده تولید شود که محصول کامل متفاوتی است. مزیت این رویکرد ترکیبی، اعتبارسنجی پیش‌فرض‌هایی است که در زمان توسعه‌ی ویژگی‌های محصول در نظر گرفته می‌شوند. توجه کنید در اسکرام، معمولا در یک زمان واحد، فقط روی یک ویژگی یا Feature کار می‌کنیم؛ ولی قرار نیست یک ویژگی را در یک مرحله تکمیل کنیم. بنابراین در پایان هر اسپرینت، PI ارزشمندی ارائه خواهیم داد که شامل چند ویژگی معدود محصول است و این ویژگی‌ها کامل و نهایی نیستند. Featureهای جدید باید با Featureهای قبلی ادغام و مقایسه شوند؛ درغیر این‌صورت طبق مفهوم Done عمل‌ نکرده‌ایم.

پس از تحویل نتایج هر اسپرینت، بازخوردی دریافت می‌کنیم که کمک می‌کند محصول تدریجی را تعدیل کنیم. بدین‌ترتیب، متوجه می‌شویم در اسپرینت آینده، باید روی کدام Featureها کار کنیم یا اینکه بهتر است فرایند‌ ساخت مجموعه‌ی بعدی Featureها را تغییر دهیم. گاهی اوقات متوجه می‌شویم Increment ما زیاد خوب نیست. در چنین حالتی، می‌توانیم برنامه‌ریزی کنیم که در اسپرینت آینده، مجددا روی Featureهای فعلی کار کنیم؛ زیرا به‌عنوان تیم اسکرام، به توسعه‌ی تدریجی و پیشرفت مداوم متعهد هستیم. هدف اسکرام این نیست که مجموعه‌ی ثابتی از فرایندهای تکراری را تعریف کنیم. جریان مداوم بازخورد به ما کمک می‌کند تعداد مؤثری اسپرینت را تکمیل کنیم و هم‌زمان، به‌تدریج محصول باکیفیتی را توسعه دهیم.

Increment محصول برای تمامی نقش‌های اسکرام مفید واقع می‌شود. برای نمونه، ذی‌نفعان و مالک محصول می‌توانند برمبنای رضایت مشتریان RIO فعلی را محاسبه کنند. به‌علاوه، شراکت و اتحاد تیم نیز به‌موازات توسعه‌ی عملکرد محصول افزایش می‌یابد؛ زیرا آن‌ها کد محصولی را ارائه می‌کنند که مسئولیت آن را در جلسه‌ی برنامه‌ریزی به‌عنوان یک تیم پذیرفته بودند.