تیم اسکرام داستان ها را به وظیفه ها تجزیه می کند تا بتواند فعالیت های درگیر در تحویل داستان ها را با جزئیات بیشتری پیگیری نماید. نهایتا، این وظیفه ها در جهت تکمیل داستان ها توسط اعضای تیم انجام می شوند. البته، پیگیری در سطح تکرار به جای تمرکز بر وظیفه ها باید بر روی داستان ها متمرکز باشد(به دلیل اینکه تمرکز بر داستان ها باعث تمرکز تیم بر ارزش کسب وکار می شود). وظیفه ها، ساختار شکست کار کوچکی را فراهم می کنند که به وسیله آن تیم ها می توانند هماهنگی، برآورد، پیگیری وضعیت و تخصیص مسئولیت به افراد را تسهیل کنند. علاوه بر این، وظیفه ها به ما کمک می کنند تا از تکمیل داستان ها و در نهایت تکمیل تکرار مطمئن شویم.
بک لاگ تیم (معمولا بک لاگ محصول یا بک لاگ پروژه نامیده می شود) شامل تمام داستان های کاربری است که تیم برای پیاده سازی شناسایی کرده است. هر تیم برای خود، بک لاگ جداگانه ای دارد که توسط مالک محصول نگهداری و اولویت بندی می شود. اگرچه ممکن است چیزهای دیگری از قبیل نقص ها، بازآرایی ها و کارهای زیرساختی و ... نیز در بک لاگ محصول وجود داشته باشند، اما داستان های کاربر پیاده سازی نشده تمرکز اصلی تیم هستند.
شناسایی، نگهداری، اولویت بندی، زمانبندی، تشریح، پیاده سازی، آزمون و پذیرش داستان های کاربر فرایند اصلی مدیریت نیازمندی ها در سازمان چابک است.
۲۷
بهمن
داستان های کاربر، جایگزین چابک همه منظوره برای «نیازمندی های نرم افزار» هستند. داستان های کاربر در ابتدا توسط ایکس پی ایجاد شده اند. در چابک، داستان های کاربر اشیاء اصلی انتقال نیازمندی های مشتری از طریق جریان ارزش(از تحلیل نیازها تا کد و پیاده سازی) هستند. بر خلاف نیازمندی ها(شرح کاری که سیستم باید برای برآورده کردن نیازهای کسب وکار انجام دهد)، داستان های کاربر «عبارت های کوتاهی از هدف» هستند و آنچه که سیستم باید برای کاربر انجام دهد را توصیف می کنند. الگوی استانداردی که برای نوشتن داستان های کاربر استفاده می شود به صورت ذیل است:
به عنوان <نقش کاربر>، من می توانم <فعالیت> برای اینکه <ارزش کسب و کار>.
با این الگو، تیم می آموزد که بر روی نقش کاربر و مزیت کسب و کاری که کارکرد جدید فراهم می کند، متمرکز شود.
۲۳
بهمن
به منظور انتشار (یا انتشار بالقوه) کارکردهای بزرگ تر برای کاربران خارجی از یک سری تکرار استفاده می شود. در تصویر کلان، به ازای هر انتشار چهار تکرار توسعه نمایش داده شده است که به دنبال آن یک تکرار تثبیت نیز قبل از انتشار آورده شده است. این الگو اختیاری است و هیچ قاعده ثابتی برای تعیین تعداد تکرارها در هر بخش قابل عرضه از محصول وجود ندارد. بسیاری از تیم ها از چهار تا پنج تکرار توسعه به همراه یک تکرار تثبیت به ازای هر انتشار استفاده می کنند که یک ریتم 90 روزه را برای بخش قابل عرضه از محصول ایجاد می کنند. این الگوی 90 روزه، آهنگ برنامه ریزی سه ماهه خوبی را برای مشتریان و خود سازمان فراهم می کند. در هر صورت، طول و تعداد تکرارها به ازای هر انتشار و تصمیم گیری برای زمان واقعی انتشار محصول به قضاوت سازمان منتهی می شود.
۱۳
بهمن
باقیمانده تیم اسکرام شامل توسعه دهندگان و آزمون گران هستند که وظیفه نوشتن و آزمون کد را بر عهده دارند. به دلیل چابک بودن این تیم، اندازه آن محدود است و شامل سه تا چهار توسعه دهنده به اضافه یک تا دو آزمون گر می باشد و به طور ایده آل در یک جا مقیم هستند و برای «تعریف، ساخت، آزمون و تحویل» داستان ها با یکدیگر کار می کنند.
۰۲
بهمن
(استاد اسکرام)
«استاد اسکرام» نقش با اهمیتی برای تیم هایی است که اسکرام را پیاده سازی می کنند. استاد اسکرام تیم را در هنگام گذار به متد جدید راهنمایی کرده و به طور مداوم هدف پویای تیم را در راستای بیشینه کردن کارایی تسهیل می کند.
۰۲
بهمن
در توسعه چابک، کارکرد جدید در رخ دادهای زمان ثابت کوتاه مدت با نام «تکرارها» (اسپرینت ها در اسکرام) ساخته می شود. در سازمان های بزرگ تر، تیم های چابک معمولا تکرارهایی با طول استاندارد را انتخاب می کنند. هر تکرار یک بخش با ارزش از کارکرد جدید را نمایش می دهد که از طریق الگوی استاندارد تکراری پایدار انجام می شود: «برنامه ریزی تکرار»، «ساخت و آزمون داستان ها»، «نمایش کارکرد جدید به ذینفعان»، «بررسی و تطبیق»، تکرار این روند.
تکرار «ضربان قلب چابکی» برای تیم است و تیم ها در این رویداد زمان ثابت کوتاه مدت بر روی توسعه کارکرد جدید متمرکز می شوند. طول تکرارها در تصویر کلان برای تمامی تیم ها یکسان در نظر گرفته شده است (به دلیل اینکه این روش ساده ترین مدل سازمانی و مدیریتی است). اگرچه برای تکرارها طول اجباری تجویز نمی شود، اما معمولا مدت زمان «دو هفته» برای آن ها پیشنهاد می شود.
۰۲
بهمن