واژه‌نامه

در این سند به تعریف و توضیح انواع مفاهیمی که در جریان کاری تیم های مهداد جاری است می پردازیم:

Scope Change
هر تغییری که باعث شود تعریف، هدف یا حجم کار یک آیتم انتخاب‌ شده در Sprint Backlog تغییر کند.
این شامل: تغییر طراحی، تغییر Acceptance Criteria، اضافه شدن استثنا یا سناریوی جدید، تغییر رفتار مورد انتظار کاربر، یا اضافه شدن قابلیت جدید است.

• Minor Scope Change (تغییر جزیی):
  • توضیح: تغییری که تاثیر محسوسی بر حجم کاری، جریان توسعه یا تست ندارد و در محدوده‌ ی AC فعلی یا فرض‌های مشترک تیم قرار دارد. معمولاً کم‌تر 2 ساعت effort و بدون نیاز به refactor.
• Major Scope Change (تغییر عمده):
  • توضیح: تغییری که نیاز به بازنگری در توسعه، تحلیل مجدد، تست گسترده یا طراحی جدید دارد. این تغییر، تعهد تیم را تغییر می‌دهد یا خروجی را دستخوش تحول می‌کند.

Sprint Backlog
مجموعه‌ای از آیتم‌ های انتخاب‌شده از Product Backlog است که تیم اسکرام متعهد شده در طول یک اسپرینت آن‌ ها را تکمیل کند. این آیتم‌ ها معمولا شامل یوزر استوری ها، تسک‌ های فنی، و فعالیت‌ های مرتبط با دستیابی به هدف اسپرینت (Sprint Goal) هستند.

• Sprint Backlog شامل موارد زیر است:
  • انواع آیتم های قابل تحویل (Selected Product Backlog Items)
  • برنامه‌ ریزی تیم برای انجام آن‌ ها (User Stories / Tasks / Sub-tasks / other Issue types)
  • هدف اسپرینت (Sprint Goal)
  • تغییرات جدید کشف‌ شده حین اسپرینت (Emergent Work)
• ویژگی‌ها:
• فقط تیم توسعه می‌تواند Sprint Backlog را تغییر دهد
• یک سند زنده است و در طول اسپرینت تکامل پیدا میکند
• تمام اعضای تیم باید شفافیت کامل نسبت به محتوای آن داشته باشند
• در جلسات Daily Scrum از محتوایی که در آن وجود دارد استفاده میکنیم.

Product Backlog
لیستی مرتب‌ شده از تمامی نیازمندی‌ ها، ویژگی‌ ها، بهبودها و رفع باگ‌هایی است که برای توسعه و تکامل محصول لازم هستند. این لیست به‌صورت مستمر توسط Product Manager و به همراهی Scrum Master در مهداد مدیریت و پالایش (Refine) می‌شود.

• ویژگی‌ها:
  • ایتم‌ها به‌ ترتیب اولویت مرتب میشوند
  • شامل User Stories، Bugs، Tasks، Improvement یا Spikes نیز میباشد
  • هر آیتم شامل توضیحات و AC های مخصوص به خود است.

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

• ویژگی‌ها:
  • توسط تیم اسکرام و PM در Sprint Planning توافق میشود
  • به عنوان معیار ارزیابی موفقیت اسپرینت استفاده میشود
  • در صورت بروز چالش یا تغییر، به عنوان مرجع تصمیم عمل میکند
  • باید Outcome Based تعیین شود.

Increment
یک نسخه قابل استفاده از محصول است که پس از تکمیل آیتم‌ های Sprint Backlog تولید میشود. این خروجی باید قابل دمو، تست، و انتشار بالقوه باشد.

• ویژگی‌ها:
  • باید با معیارهای Definition of Done مطابقت داشته باشد
  • هر اسپرینت حداقل یک Increment ایجاد کنیم.
  • ممکن است شامل یک یا چند ویژگی جدید یا بهبود باشد
  • تیم باید اطمینان حاصل کند که Increment پایدار و تست‌ شده است.

Definition of Ready (DoR)
DoR مجموعه‌ ای از معیارهاست که مشخص میکند یک آیتم از Product Backlog به اندازه‌ی کافی واضح و آماده است که وارد Sprint Backlog شود.

Definition of Done (DoD)
DoD یک توافق تیمی است که مشخص میکند چه زمانی یک آیتم به‌طور کامل Done محسوب میشود. این تعریف شامل معیارهای فنی، کیفی و تحویلی است که تیم باید رعایت کند.(DOD میتواند محدود به یک اسپرینت خاص تعریف شود)

Acceptance Criteria (AC)
Acceptance Criteria مجموعه‌ ای از شرایط واضح و قابل تست است که مشخص می‌کند چه چیزی باعث می‌شود یک User Story مورد تایید قرار گیرد. این معیارها دید مشترکی بین Dev، QA و PM ایجاد می‌ کنند.

• ویژگی‌ها:
  • از زبان ساده و قابل تست استفاده میکنند
  • معمولاً با فرمت خاص نوشته میشوند
  • اساس تست‌ های QA و راهنمای توسعه‌ دهنده هستند.

Velocity
Velocity عددی است که نشان میدهد تیم در یک اسپرینت چه مقدار Story Point واقعی تحویل داده است. این شاخص در پیشبینی ظرفیت آینده و برنامه ریزی انتشار محصول بسیار مهم است.

• ویژگی‌ها:
  • فقط Story های کامل‌ شده (Done) لحاظ می‌ شوند
  • میانگین Velocity چند اسپرینت، پایه‌ ی Forecast بعدی است
  • به تیم کمک می‌ کند ظرفیت واقعی خودش را بشناسد

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

• ویژگی‌ها:
  • معمولا تایم‌ باکس‌ شده است (مثلا 4 ساعت یا 1 روز)
  • در Product Backlog با نوع خاص (Spike) مشخص می‌ شود
  • خروجی می‌ تواند شامل نمونه‌ کد، نمودار، گزینه‌ های تصمیم یا مستندات باشد

Technical Debt
بدهی فنی (Technical Debt) به انتخاب‌های تکنیکی غیربهینه یا ناقصی گفته می‌ شود که به‌ منظور تحویل سریع‌تر انجام شده‌اند، اما در آینده نیاز به باز پرداخت دارند (مثلاً با refactor، باز نویسی یا بهبود کیفیت کد).

• ویژگی‌ها:
  • گاهی آگاهانه و گاهی ناخواسته ایجاد می‌شود
  • اگر مدیریت نشود، باعث افزایش هزینه نگهداری و کندی توسعه می‌ شود
  • تیم باید به‌ صورت مستمر آن را شناسایی و در Backlog (پروژه ی Bug & Idea مربوط به هر پروژه یا سند توافق شده با مدیر محصول با تگ (Tech debt) ثبت کند

انواع Issue Type

• تسک (Task)
  • توضیح: یک مورد عملی و مشخص که برای تکمیل یک داستان کاربری (َUser Story) یا پشتیبانی از یک ویژگی(Feature) لازم است، اغلب از جنس فنی (مثلاً بازنویسی کد، بهینه‌ سازی پایگاه داده).
  • هدف: برای کنترل پیشرفت هدف اسپرینت به منظور نظارت دقیق تر و پیگیری ساده تر و شفافیت بیشتر در خصوص یوزر استوری ها از این نوع تایپ استفاده میکنیم.
• داستان کاربری (Story)
  • توضیح: یک الزام متمرکز بر کاربر که ارزش ایجاد می‌ کند، معمولاً با فرمت "به‌عنوان یک [کاربر]، می‌خواهم [ویژگی] تا [فایده]" نوشته می‌ شود. As a ….I Want …So i can …
  • هدف: ما این مدل تسک ها را هم راستا با توسعه ی نیاز های مشتری و اهداف محصولمون مینویسیم که ساختار آن که چه مواردی را باید شامل شود که ما آن را وارد چرخه ی توسعه کنیم به تفکیک در سند DOR نوشته شده است.
• باگ (Bug)
  • توضیح: یک نقص یا خطای غیرمنتظره در عملکرد موجود که از رفتار مورد انتظار منحرف شده است.
  • هدف: ما باگ ها را برای افزایش کیفیت محصول و تضمین کیفیت محصولمون ایجاد میکنیم که اولویت بندی انجام آن مستقیم با پروداکت منیجر هر پروژه است.
• بهبود (Improvement)
  • توضیح: پیشنهادی برای بهبود یا بهینه‌ سازی فرآیند ها، کد یا ویژگی‌ های موجود که مستقیماً عملکرد جدیدی اضافه نمی‌ کند.این نوع از تسک ها متفاوت از یوزر استوری ها میباشند و در باطن نباید فیچر جدیدی به محصول اضافه کند.
  • هدف: برای پیشبرد بهبود مستمر در پروژه و رفع بدهی های فنی پروژه از این نوع تسک استفاده میکنیم.
• اپیکها (Epic - Feature)
  • توضیح: یک قابلیت جدید یا عملکرد اصلی که شامل چندین داستان(Story) یا تسک(Task) است.
  • هدف: این تسک ها برای پیشبرد و برنامه ریزی برای توسعه ی محصول در بلند مدت ایجاد میشوند.

سطوح اولویت‌بندی در پروژه‌ها

• بالاترین اولویت (Urgent)
  • توضیح: مسائل یا ویژگی‌ های بحرانی که به دلیل تأثیر شدید بر کاربران، درآمد یا پایداری سیستم نیاز به توجه فوری دارند.
  • معیار ها: تشخیص این اولویت با پروداکت منیجر هر پروژه است اما به طور معمول قطعی سیستم، آسیب‌ پذیری‌ های امنیتی یا موانع گزارش‌ شده توسط مشتری و …
• بالا (High)
  • توضیح: تسک‌ ها یا باگ‌ های مهمی که به‌ طور قابل‌ توجهی تجربه کاربر یا اهداف تجاری را تحت تأثیر قرار می‌دهند و نیاز به رفع سریع دارند.
  • معیار ها: تشخیص این اولویت با پروداکت منیجر هر پروژه است اما به طور معمول شکایات مکرر کاربران یا تأخیر در ویژگی‌ های کلیدی و …
• متوسط (Medium)
  • توضیح: تسک‌ ها یا باگ‌ هایی که پیشرفت مداوم را پشتیبانی می‌کنند اما خطر یا فوریت فوری ندارند.
  • معیار ها: تشخیص این اولویت با پروداکت منیجر هر پروژه است اما به طور معمول باگ‌ های غیر بحرانی یا بهبود هایی با تأثیر متوسط بر کاربر و …
• پایین (Low)
  • توضیح: مسائل یا بهبود هایی با تأثیر جزئی که می‌ توانند به تعویق بیفتند بدون عواقب قابل‌ توجه.
  • معیار ها: تشخیص این اولویت با پروداکت منیجر هر پروژه است اما به طور معمول رفع‌ های ظاهری یا درخواست‌ های کم‌ اهمیت کاربر و …
• پایین‌ ترین ( No Priority )
  • توضیح: تسک‌ها یا بهبود هایی با تأثیر ناچیز که برای اسپرینت‌ های آینده یا زمان اضافی برنامه‌ ریزی می‌شوند.
  • معیار ها: تشخیص این اولویت با پروداکت منیجر هر پروژه است اما به طور معمول بدهی فنی بلند مدت یا فیچر دلخواه و …

Severity

شدت یک باگ را از نظر تاثیر فنی بر روی سیستم مشخص می‌کند (Critical, High, Medium, Low). این شاخص، اولویت رفع را تعیین نمی‌کند، بلکه صرفاً میزان وخامت فنی باگ را توصیف می‌کند.

انواع Severity با جزئیات

۱. Critical (بحرانی)

• **تعریف:**باگ‌هایی که باعث عدم کارکرد کامل سیستم، کرش‌کردن برنامه، یا از دست رفتن داده‌ها می‌شوند.
• مثال:
  • نرم‌افزار اجرا نمی‌شود
  • پرداخت نهایی در فروشگاه آنلاین کار نمی‌کند
  • کرش کردن اپلیکیشن هنگام Login

۲. High (زیاد)

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

۳. Medium (متوسط)

• **تعریف:**باگ‌هایی که تأثیر متوسطی روی عملکرد دارند یا یک امکان جانبی را مختل می‌کنند؛ سیستم اصلی هنوز کار می‌کند.
• مثال:
  • گزینه فیلترینگ نتایج درست کار نمی‌کند
  • خطای ظاهری در نمایش داده‌های غیرحیاتی

۴. Low (کم)

• **تعریف:**باگ‌هایی با تأثیر جزئی یا ظاهری که عملکرد سیستم را مختل نمی‌کنند و فقط ظاهر یا تجربه کاربری را تحت تاثیر قرار می‌دهند.
• مثال:
  • جا‌به‌جایی متن یا تصویر (Alignment مشکل دارد)
  • اشتباه تایپی یا غلط املایی

نکته:

• تعیین Severity با تستر و تیم QA است.
• اولویت (Priority) توسط مدیر محصول بسته به نیاز تجاری/زمان‌بندی تعیین می‌شود.

مراسم اسکرامی

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

• جلسه Grooming
  • هدف: هدف از جلسه Grooming، هم راستا سازی تیم توسعه با آیتم‌ هایی از بک‌ لاگ محصول است که قرار است در اسپرینت‌ یا اسپرینت های آینده وارد شوند. در این جلسه روی آیتم‌ هایی تمرکز می‌شود که نزدیک به ورود به Sprint Backlog هستند.
  • تکرار: به صورت هفتگی یک بار یا دوبار بنا به نیاز برگزار میشود.
  • زمان: 1 ساعت
  • دستور جلسه
    • تسک هایی که توی بک لاگ وجود داره ( که توسط Pm ساخته شده ) رو بررسی میکنیم براشون استیمیت مشخص میکنیم و دیپندنسی هاش رو شناسایی میکنیم و اگر نکته ای برای هر تسک وجود داره که باید به هم یادآوری کنیم رو به هم میگیم.
    • در صورت نیاز یوزر استوری‌ ها به تسک‌ یا Sub-task‌ تبدیل شوند.
    • سناریوها بررسی و بهبود داده می شود
    • ابهامات فنی، منطقی یا تجربه کاربری روشن می شود
• جلسه Sprint Planning
  • هدف: تعریف هدف اسپرینت و تعهد به مجموعه‌ ای از تسک ها که برای اسپرینت آینده متعهد به تحویل آن ها شده ایم.
  • تکرار: هر دو هفته یکبار
  • زمان: 2 ساعت
  • دستور جلسه
    • در صورت نیاز میتونیم اول جلسه یه گرومینگ نیم ساعته انجام بدیم
    • هدف اسپرینت توسط پروداکت منیجر برامون توضیح داده میشه
    • از آیتم های موجود در بک لاگ با توجه به ظرفیت اسپرینت مواردی رو انتخاب میکنیم
    • در ارتباط با موارد انتخاب شده همه ی تیم متعهد میشیم که موارد رو برای محصول مورد نظر تحویل دهیم
• جلسه Daily Standup
  • هدف: همگام‌ سازی تیم، شناسایی موانع، و ردیابی پیشرفت به سمت هدف اسپرینت این جلسه بسیار مهم است برای اینکه ما بتونیم نظارت کنیم که در مسیر درستی به سمت هدف اسپرینت حرکت میکنیم و اگر مانعی توی این مسیر وجود داره بتونیم خیلی زود با تعامل با همدیگه برطرفش کنیم.
  • تکرار: روزانه
  • زمان : 15 دقیقه
• دستور جلسه
  • در هر دیلی به سه سوال مهم جواب میدیم
    • روز قبلی روی چه تسکی کار کردیم ؟ با اعلام کد تسک
    • امروز قراره روی چه تسکی کار کنیم ؟ با اعلام کد تسک
    • آیا برای کاری که دیروز انجام دادیم یا امروز بلاکری وجود داره یا نه؟ پیگیری مستمر با اسکرام مستر
  • نکات:
    • روزهای پلنینگ و روز های تعطیل دیلی برگزار نمیشود
    • این جلسه برای توسعه دهندگان در اسپرینت است
    • صحبت های خارج از سه سوال مطرح شده باید در اخر جلسه با نفرات مرتبط برگزار شود که به وقت دیگران احترام گذاشته شود"
    • سوال سوم نقطه ی کلیدی این جلسه است که اسکرام مستر بتواند موانع را شناسایی و در صدد رفع آن پیگیری های لازم را انجام دهد.
• جلسه Sprint Review
  • هدف: این جلسه برای بازبینی ارزش هایی هست که توانستیم حین اسپرینت اون هارو برای محصول Deliver کنیم . هدف بازبینی تسک هایی است که در ستون Done در بردهای اسپرینت پروژه وجود دارند.
  • تکرار: پایان هر اسپرینت
  • زمان : 1 ساعت
  • دستور جلسه:
    • در ابتدای جلسه توسط پروداکت منیجر هدفی که برای اسپرینت داشتیم را بازبینی میکنیم بعد یکی یکی توسط توسعه دهنده ها موارد مربوط انجام شده را برای حاضرین در جلسه Share میکنیم.
      • بهتر است مواردی را که مربوط به هم هستند یکجا و توسط یک شخص دمو شود به این صورت که شماره ی تسک ها در ابتدا اعلام و سپس توسط اون فرد به نمایش گذاشته میشود (مثلا تسک های ۱۸۸۸ - ۱۸۹۸ - ۱۸۹۹ شامل تسک های فرانت و بک مشترک هستند، باید توسط یک شخص به نمایندگی از خود اون افراد دمو شود)
    • در انتهای جلسه پروداکت منیجر باید در رودمپ محصول به ما نشان دهد که این ارزش های خلق شده در اسپرینت چه بخشی از رود مپ مارو پیش برده اند.
• جلسه Retrospective
  • هدف: شناسایی ٬ کشف نقاط ضعف و قوت عملکرد تیم در مسیر اسپرینت از اهداف اصلی این جلسه است رترو مثل آینه‌ ایه از اسپرینتی که گذروندیم اینکه چی خوب بود، چی جای بهبود داشت، و چطوری می‌ تونیم تیم رو یک درصد بهتر کنیم میریم توی این جلسه که کاملا شفاف و صادقانه و بدون ترس از قضاوت شدن به بهبود فرآیند هامون کمک کنیم و نقاط ضعفمون رو به قوت تبدیل کنیم.
  • تکرار: انتهای هر اسپرینت به حسب نیاز(SM تصمیم میگیره)
  • زمان : 1 ساعت
  • دستور جلسه
    • در این جلسه چهار ستون مهم داریم که هر یک را با توجه به محتوای خواسته شده پر میکنیم
      • Went Well - توی اسپرینتمون چی خوب پیش رفت؟(نقاط قوتمون)
      • To Improve – چی می‌ تونست توی اسپرینت بهتر پیش بره؟(نقاط ضعفمون)
      • Action Items – پیشنهاد برای بهبود(ستون مهمی که روش اکشن پلن مینویسیم)
      • Questions / Confusions – سوال یا ابهام(اگر در فرآیندهامون سوال یا ابهامی داری اینجا مینویسی و توی جلسه با هم بررسیش میکنیم)
  • نکات:
    • همه ی اعضای تیم یک ساعت قبل از جلسه زمان میزارن و ستون های مربوط رو با کارت پر میکنن ( به تعداد دلخواه و آزادانه برای نوشتن و طرح هر موضوعی مربوط به همان اسپرینت)
    • کارت هایی که از نظر شما اهمیت بیشتری دارد را رای بدهید تا توی جلسه به تفصیل راجع به اون ها صحبت کنیم
    • در رترواسپکتیو های بعدی مواردی که در اکشن پلن نوشته بودیم رو پیگیری میکنیم که در این اسپرینت فیکس شده بودن یا نه ( رعایت همه ی مواردی که در ستون اکشن پلن هستند موجب بهبود فرآیند تیمی میشود)
    • توجه به گروه های تیمی در نرم افزار Wave برای اطلاع رسانی ادرس بورد الزامی است.
• Backlog Refinement
  • هدف: Backlog Refinement یک فرآیند مستمر و مشارکتی است که هدف آن شفاف‌ سازی، اولویت‌ بندی و آمادگی آیتم‌ های بک‌لاگ محصول برای آینده است. در این فرآیند، آیتم‌های بک‌ لاگ بررسی می‌شوند
  • تکرار: روزانه
  • زمان : 15 دقیقه
• دستور جلسه
  • در این جلسه که به صورت مستمر بین PM & SM و در صورت نیاز عضو مربوطه در تیم فنی اجرا میشود:
    • ابهامات را برطرف میکنیم
    • در این پروسه AC ها را اصلاح یا تکمیل میکنیم
    • وابستگی‌ ها یا ریسک‌ ها را شناسایی میکنیم
    • آیتم‌های بزرگ را از لحاظ محصولی شکسته یا مجدد مینویسیم.
  • نکات:
    • این یک فرآیند غیر رسمی در دل توسعه ی محصول و برای مدیریت بک لاگ است
• Design Handoff
  • هدف: اطمینان از اینکه طراحی به‌ طور کامل، دقیق و قابل اجرا به تیم توسعه تحویل داده شده و هیچ ابهامی در مورد رفتار، تعامل یا جزئیات UI وجود ندارد.
  • تکرار: یک بار در هر اسپرینت
  • زمان : 45 دقیقه(بسته به نیاز)
• دستور جلسه
  • در این جلسه که بین طراح و دولوپر مورد نظر برگزار میشود:
    • معرفی کلی طراحی‌ های آماده‌ شده (Figma walkthrough)
    • بررسی تمام حالات UI: ‌error, loading, empty, success
    • مرور تعامل‌ ها (interactions) و رفتار های خاص (micro animations, conditional logic)
    • بررسی هم‌راستایی با Design System (پنتوگراف)
    • پاسخ به سوالات Dev و شناسایی موارد مبهم
    • ثبت موارد ناقص یا مورد نیاز برای اصلاح (در Task یا Comment)
  • نکات:
    • اگر طراحی incomplete باشد، نباید استوری وارد Sprint Backlog شود
    • Designer و دولوپر مسئول هستند که روی «کامل بودن» طراحی توافق داشته باشند
    • خروجی جلسه باید مستند شده و در تسک در اکتاپل نوشته شده باشد
• Tech Kickoff
  • هدف: هم‌راستاسازی تیم توسعه روی معماری کلی، ساختار API ها، تقسیم وظایف و اولویت‌ های فنی برای شروع به‌ موقع و دقیق اسپرینت
  • تکرار: یک بار در هر اسپرینت بعد از اسپرینت پلنینگ
  • زمان : 45 دقیقه(بسته به نیاز)
• دستور جلسه
  • در این جلسه که بین تک لید و تمام دولوپر ها برگزار میشود:
    • بررسی معماری کلی مورد نیاز برای هر فیچر
    • مرور API هایی که باید ساخته یا مصرف شوند
    • شناسایی تسک‌هایی که به هم وابسته هستند
    • تقسیم وظایف (Ownership Story ها) بین دولوپر ها
    • مرور Technical Riskها، یا تصمیم‌ های معماری خاص
    • تصمیم درباره ابزار ها یا کتابخانه‌ های خاص مورد نیاز
  • نکات:
    • حضور Tech Lead یا معمار نرم‌ افزار ضروریه
    • یک نفر باید به طور کامل Ownership تسک را به عهده بگیرد.
• QA Alignment
  • هدف: هم‌ راستا سازی تیم تست و توسعه بر سر استراتژی تست، سناریو ها، ابزار تست و نقاط حساس برای هر فیچر قبل از شروع تست عملی
  • تکرار: درست قبل از شروع QA
  • زمان : 30 دقیقه(بسته به نیاز )
• دستور جلسه
  • در این جلسه که بین تستر مورد نظر و دولوپر مورد نظر برگزار میشود:
    • مرور User Story ها یا تسک ها یا باگ هایی که وارد فاز تست می‌ شوند
    • چه مدل تستی قراره روی تسک انجام شود؟ تعیین گردد.
    • بررسی ورودی‌ های مورد نیاز برای تست(دیتاها در اختیار تستر قرار گیرد)
    • چک کردن کامل بودن ACs
    • شناسایی سناریوهای Edge Case و وضعیت‌های استثنا برای اون ایتم
    • هم صفحه شدن تستر و دولوپر برای نتیجه ی مورد انتظار خروجی
  • نکات:
    • QA نباید بدون این جلسه تست رو شروع کنه. این زمانیه که Dev و QA هم صفحه میشن
    • اگر با فورس زمانی توی اسپرینت مواجه باشیم باید لیست سوالات قبل جلسه انجام شود
    • میتونن تصمیم بگیرن تست رو کجا انجام بدن توی محیط استیج یا لوکال