آموزش اسکرام؛ قسمت هشتم: داستان‌های کاربر و تعریف Done

در قسمت‌های گذشته، اشاره کردیم در پایان اسپرینت، باید محصول Potentially Shippable داشته باشیم؛ یعنی محصولی که به‌طوربالقوه عرضه‌کردنی است. این اصطلاح به ما اطمینان می‌دهد آنچه در طول اسپرینت توسعه داده‌ایم، واقعا انجام‌‌شده (Done) است. محصول قابل‌عرضه یا قابل‌انتشار هیچ کار انجام‌نشده و ناتمامی ندارد و آماده‌ی ارائه یا ارسال است. اگر تیم‌های توسعه چنین محصولی تولید کرده باشند؛ پس، حتما در مراحل قبلی، تعریف Done به‌خوبی توصیف‌شده و موردتوافق همگان قرار گرفته است.

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

• ماهیت محصولی که توسعه می‌یابد.
• تکنولوژی‌هایی که برای توسعه‌ی محصول استفاده می‌شود.
• سازمانی که می‌خواهد محصول را توسعه دهد.
• موانع موجود که احتمالات را تحت‌تأثیر قرار می‌دهند.

تعریف Done ممکن است در پروژه‌ها و تیم‌های مختلف متفاوت باشد؛ اما باید مطمئن شویم DoD پیش از آغاز اولین اسپرینت، موردتوافق همگان قرار گرفته است. به‌گفته‌ی سازمان اسکرام آلیانس، سه نوع DoD وجود دارد:

• تعریف Done برای یک ویژگی (داستان کاربر یا آیتم بک‌لاگ محصول)
• تعریف Done برای یک اسپرینت
• تعریف Done برای یک ریلیز (Release)

DoD برای اعضای تیم ابزار گزارش‌دهی مفیدی محسوب می‌شود؛ زیرا مشخص می‌کند یک ویژگی کاملا تکمیل‌ شده است. بدین‌ترتیب، اعضای تیم به‌راحتی می‌توانند به‌روزرسانی‌ها را برای سایر اعضای تیم و مالک محصول توضیح دهند. در تصویر زیر، نمونه‌ای از چک‌فهرست تعریف Done را مشاهده می‌کنید:

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

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

همان‌طورکه در توضیح روش اجرای اسپرینت اشاره کردیم، در طول اسپرینت، هر آیتم بک‌لاگ محصول باید مطابق با مجموعه‌ای از شرایط تکمیل شود. این شرایط را مالک محصول تعیین می‌‌کند و معیارهای پذیرش (Acceptance Criteria) نام دارد. معیارهای پذیرش درنهایت در آزمون پذیرش بررسی و اعتبارسنجی و تأیید می‌شوند. فرض کنید آیتم بک‌لاگ محصول این‌گونه تعریف‌شده: «مشتری می‌خواهد لباس‌های خود را به‌صورت آنلاین بخرد». گزینه‌های او برای انتخاب وب‌سایت‌های خرید عبارت‌اند از: «آمازون، مینترا، فلیپ‌کارت و Jabong».

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

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

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

داستان آماده یا داستان مشروح و باجزئیات کاربر، لزوما از دو عنصر زیر برخوردار است:

• یک روایت
• معیارهای پذیرش

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

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

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

• داستان باید دقیقا در قالب «داستان کاربر» نوشته شود.
• تیم باید معیارهای پذیرش را به‌خوبی درک کند.
•  تیم به ارزیابی و برآورد داستان نیاز دارد.
• تیم باید بداند چگونه دمو فیچرها را آماده کند.
• تیم باید معیارهای عملکرد را به‌خوبی درک کند.

موارد یادشده، اطلاعات موردنیاز تیم را برای تکمیل داستان خاص فراهم می‌کند.

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

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

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

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

نکته: تعریف Ready احتمال دوباره‌کاری‌ها را در داستان کاربر به‌حداقل می‌رساند.

داستان یا استوری کاربر (User Story) بخشی از رویکرد توسعه‌ی نرم‌افزار چابک است که جزئیات الزامات یا نیازمندی‌ها را از دیدگاه کاربر نهایی بیان می‌کند. داستان کاربر مشخص می‌کند شما چه نوع کاربری هستید و چه چیزی می‌خواهید و چه دلیلی پشت این خواستن وجود دارد. به‌عبارت ساده، داستان کاربر به تیم چابک کمک می‌کند توصیفی کوتاه و ساده از الزامات کار را از نگاه کاربر ذکر کند.

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

سال ۱۹۹۹، کنت بک اولین‌بار اصطلاح داستان‌های کاربر را برای ویژگی‌های محصول به‌کار برد. او توضیح داد کلمه‌ی داستان کاربر بهترین توصیف از دیدگاه مشتری برای چیزی است که او می‌خواهد (به‌جای کارهایی که سیستم ترجیح می‌دهد برای مشتری انجام دهد). به‌همین‌دلیل، چشم‌انداز کار دستخوش برخی اصلاحات شد: تمرکز تیم از محصول به کاربر نهایی تغییر یافت و داستان‌های کاربر به استاندارد واقعی الزامات همه‌ی فرایندها چابک تبدیل شد.

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

تیم‌های اسکرام عموما رویکرد ساده‌ای برای داستان‌های کاربر دنبال می‌کنند:

• من به‌عنوان ، را می‌خواهم، به‌طوری‌که

یا

• من به‌عنوان ، چیزی را می‌خواهم ؛ زیرا

پس دقیقا «داستان کاربر» را به چه منظوری استفاده می‌کنیم؟ رون جفریس، یکی از امضاکنندگان مانیفست اجایل، راهکار ساده و مؤثری برای توضیح داستان‌های کاربر ارائه می‌دهد که شامل سه عنصر است: کارت (Card) و مکالمات (Conversation) و تأیید (Confirmation).

کارت: ایده‌ی یادداشت‌کردن داستان‌ها روی کارت بسیار ساده است. ما داستان‌های کاربر را روی کارت‌ها یا کاغذهای یادداشت چسبداری در قطع ۱۲.۵ در ۷.۵ سانتی‌متر می‌نویسیم. ساختار داستان کاربر باید سه مسئله را مشخص کند: ۱. با چه نوع کاربری در ارتباط هستیم؛ ۲. این کاربر چه چیزی می‌خواهد؛ ۳. به چه دلیل چنین هدفی دنبال می‌کند. قرار نیست تمام اطلاعات مربوط‌به الزامات محصول را روی کارت بنویسیم. درواقع، ما از کارت‌های کوچک استفاده می‌کنیم تا نیاز مشتری را در چند خط کوتاه خلاصه کنیم. جزئیات داستان در بخش بعدی، یعنی گفت‌وگوها و مکالمه‌ها عنوان می‌شود.

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

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

داستان‌های کاربر یکی از بهترین کانال‌هایی هستند که آیتم‌های ذی‌نفعان و ایده‌ی کاربران را به جریان «ایجاد ارزش» اسکرام وارد می‌کنند. در سطح اسپرینت، تعداد داستان‌ها بسیار زیاد و اندازه‌ی آن‌ها بسیار کوچک است؛ چراکه در این حالت، داستان‌ها از برنامه‌ریزی Release و محصولات سطوح بالاتر پشتیبانی می‌کنند. در این سطوح، به آیتم‌های انتزاعی‌تر و داستان‌هایی با جزئیات کمتر نیاز داریم؛ درغیر‌این صورت، در دام جزئیات غیرمرتبط گرفتار می‌شویم. بنابراین در سطح اسپرینت، هرگز حماسه (Epic) را توسعه نمی‌دهیم؛ زیرا حماسه مفصل و بغرنج است و جزئیات آن مشخص نیست. درعوض، می‌توانیم حماسه را به چندین داستان کاربر با جزئیات مشخص تبدیل و در چندین اسپرینت تکمیل کنیم یا آن را به‌عنوان پروژه‌ای جدید به تیم دیگری معرفی کنیم.

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

• Independent: مستقل از سایرین
• Negotiable: مذاکره‌کردنی 
• Valuable: ارزشمند
• Estimable: تخمین‌زدنی یا برآوردکردنی (با تقریب خوب)
• Small: کوچک (اجرا‌شدنی در طول یک اسپرینت)
• Testable: آزمایش‌کردنی

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

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

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

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

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

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

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