تستر در Sprint Review؛ از Demo تا Outcome Adaptation

Sprint Review زمانی شکست می‌خورد که یک Demo از مسیر موفق اجرا شود، چند نفر بگویند «عالی است» و تیم بدون تغییر Product Backlog جلسه را ترک کند. اجرای بی‌خطای سناریوی نمایشی، رأی تأیید و تعداد تست‌ها نشان نمی‌دهد Increment درست، Done و قابل استفاده بوده؛ Outcome برای ذی‌نفع واقعی ارزش دارد؛ Evidence به Build نمایش‌داده‌شده تعلق دارد؛ یا بازخورد به تصمیم و Adaptation تبدیل شده است.

نقش قابلیت تست در Sprint Review، اجرای «دموی QA» یا تأیید کیفیت نیست. این قابلیت کمک می‌کند تیم و ذی‌نفعان یک Outcome واقعی را با Context و محدودیت‌هایش بازرسی کنند، فاصلهٔ Product Goal تا Evidence را ببینند، بازخورد قابل‌ردیابی بسازند و دربارهٔ گام بعد تصمیم بگیرند. Sprint Review یک Working session است؛ نه ارائهٔ یک‌طرفه، UAT، Defect triage، Retrospective یا Release gate.

پاسخ کوتاه: Review شواهدمحور چه حلقه‌ای می‌سازد؟

Current Product Goal + environment changes
 -> inspect the Done, usable Increment
 -> observe stakeholder outcomes in context
 -> expose bounded evidence, risks and unknowns
 -> capture feedback as observations, not votes
 -> compare options and trade-offs
 -> decide adaptations
 -> update Product Backlog and follow-up records

Review موفق لازم نیست حتماً Backlog را عوض کند؛ ممکن است Evidence فعلی جهت را پشتیبانی کند. اما باید امکان واقعی بازرسی و Adaptation وجود داشته باشد. اگر نتیجه از پیش تعیین شده و Feedback فقط تشریفاتی است، رویداد به Show-and-tell تبدیل شده است.

Sprint Review در Scrum رسمی

عنصر	تعریف	برداشت نادرست
Purpose	بازرسی Outcome اسپرینت و تعیین Adaptationهای آینده	Demo قابلیت‌ها
Participants	Scrum Team و ذی‌نفعان کلیدی	PO به‌عنوان داور و QA به‌عنوان تأییدکننده
موضوع	آنچه انجام شده و تغییرهای محیط	فقط فهرست Ticketهای بسته
شکل	Working session	Presentation یک‌طرفه
Adaptation	همکاری دربارهٔ کار بعد؛ Backlog ممکن است تغییر کند	ثبت چند نظر بدون تصمیم
Release	Review Gate انتشار نیست	انتظار Sign-off تا پایان Sprint

راهنمای Scrum ۲۰۲۰ صریحاً می‌گوید Sprint Review نباید به ارائه محدود شود و Increment می‌تواند پیش از پایان Sprint به ذی‌نفع تحویل شود؛ Review هرگز Gate انتشار تلقی نمی‌شود. فقط Work مطابق Definition of Done بخشی از Increment است. منبع: Scrum Guide 2020.

مرز Sprint Review با رویدادها و Artifactهای نزدیک

فعالیت	پرسش اصلی	مرز
Sprint Planning	Why/What/How Sprint چیست؟	Plan آغازین Sprint
Daily Scrum	Plan امروز چگونه با Goal سازگار شود؟	Evidence Flow روزانه
Sprint Review	Outcome و محیط چه Adaptation محصولی می‌طلبد؟	همین مقاله
Retrospective	کیفیت و اثربخشی شیوهٔ کار چگونه بهتر شود؟	فرایند/تعامل/ابزار/DoD
UAT	آیا کاربران/Authority شرایط پذیرش Context را برآورده می‌دانند؟	چرخهٔ پذیرش کاربر
Test Results presentation	Evidence چگونه برای یک تصمیم ارائه شود؟	ارائهٔ نتایج تست
Release decision	آیا با ورودی‌ها/Authority تعیین‌شده منتشر شود؟	Status و Release packet

Tester قهرمان انحصاری کیفیت نیست

در Scrum، Scrum Team یک واحد cross-functional بدون زیرتیم QA/Development است و کل تیم برای Increment ارزشمند و مفید پاسخ‌گوست. فرد دارای قابلیت Testing می‌تواند Evidence، Oracle، Risk، Failure behavior و محدودیت استنتاج را روشن کند؛ فرد Domain، Operations، Accessibility یا Security Perspective دیگری می‌آورد. هیچ‌کدام به‌تنهایی «صدای کیفیت» یا نمایندهٔ همهٔ کاربران نیستند.

قابلیت	Contribution در Review	ادعای نامجاز
Product	Goal/value/options/trade-off	تنها صدای همهٔ ذی‌نفعان
Testing	Evidence/unknown/risk/oracle/limitations	تضمین کیفیت یا Done sign-off
Development	رفتار/architecture/feasibility	فقط Happy-path demo
Operations/support	workflow/recovery/observability	نمایندگی همهٔ Production
Accessibility/user research	interaction/participant evidence	اثبات پذیرش همهٔ کاربران
Stakeholder	Context/need/change/constraint	رأی شخصی به‌عنوان بازار

Review Contract قابل‌کپی

SprintReviewContract {
  review_id, sprint_id,
  product_goal_id, sprint_goal_id,
  increment_id, build_digest,
  definition_of_done_version,
  product_backlog_snapshot,
  environment_snapshot, facts_as_of,
  stakeholder_contexts[],
  outcome_questions[],
  evidence_profile[],
  known_risks_and_unknowns[],
  interaction_format,
  feedback_schema,
  decision_and_adaptation_policy,
  record_owner, access_and_retention
}

این Contract الزام Scrum نیست؛ راهی برای جلوگیری از نمایش Build اشتباه، دادهٔ نمایشی نامعلوم و رأی‌های بی‌Context است. Review می‌تواند سبک باشد، اما هویت Increment/Build/Goal و محل ثبت Feedback/Adaptation نباید با حدس پر شود.

فقط Increment Done را به‌عنوان Increment ارائه کنید

Work ناقص می‌تواند برای شفافیت یا Conversation نشان داده شود، اما باید صریحاً Prototype/WIP/Experiment نامیده شود؛ طبق Scrum جزو Increment نیست، قابل Release یا حتی ارائه به‌عنوان Increment در Review نیست. مخلوط‌کردن Done و WIP در یک Demo، ذی‌نفع را دربارهٔ واقعیت محصول گمراه می‌کند.

وضعیت	نحوهٔ نمایش	Claim مجاز
Done Increment	محصول قابل استفاده با Build/DoD مشخص	Outcome محدود در Conditions آزموده‌شده
Prototype	برچسب Prototype و سؤال یادگیری	Concept feedback، نه readiness
WIP	فقط برای شفافیت Plan/option	Work incomplete
Mock/Fake	مرز fidelity و componentهای fake	Interaction محدود
Recorded demo	Build/time/context recording	رفتار همان Snapshot
Slide	پشتیبان Evidence/Trend	جای Increment را نمی‌گیرد

Demo باید Outcome را قابل بازرسی کند

کدام Actor/Workflow و مسئله/Outcome در Product Goal مطرح است؟
این Increment چه Contribution ادعایی دارد؟
ذی‌نفع چه کار واقعی یا نزدیک به واقعیت می‌تواند انجام دهد؟
کدام مسیر/شرط/Failure برای تصمیم امروز معنادار است؟
چه چیزی عمداً خارج از Scope و Evidence است؟
چه مشاهده‌ای می‌تواند فرض فعلی را رد یا تغییر دهد؟

Script خشک که فقط بدون خطا اجرا می‌شود، Confirmation bias می‌سازد. اجازه دهید ذی‌نفع با محصول کار کند، سؤال بپرسد و Context خود را وارد کند؛ اما از یک مشاهدهٔ فردی به همهٔ کاربران یا بازار تعمیم ندهید.

Outcome با Output و Activity فرق دارد

لایه	نمونه	چه چیزی را اثبات نمی‌کند؟
Activity	۲۰۰ تست اجرا شد	کفایت یا ارزش
Output	Feature/endpoint ساخته شد	استفاده/Outcome
Behavior	Retry در Lab duplicate effect نساخت	Production distribution
User outcome	وظیفه در Sample سریع‌تر انجام شد	همهٔ کاربران/علت قطعی
Business outcome	Conversion/هزینه/Support تغییر کرد	Causality بدون طرح مناسب
Product Goal progress	Evidence چند Outcome/فرض	Goal achieved مگر Gate روشن

Evidence را با Claim و محدودیت ارائه کنید

ReviewEvidenceClaim {
  claim_id, outcome_or_risk,
  population_and_context,
  increment_and_build_id,
  data_environment_oracle_refs[],
  evidence_refs[], observed_result,
  unknowns[], limitations[],
  confidence_rationale,
  decision_supported,
  explicitly_not_proven[]
}

«۲۰۰ تست و ۸۵٪ Coverage، پس پرداخت بدون Regression است» یک جهش استنتاج است. بگویید کدام Coverage Registry، کدام Build/Population/Risk، چه Outcome و چه Gapهایی. Evidence باید فهم و تصمیم را بهتر کند، نه اعتماد نمایشی بسازد.

Product Goal Progress Claim

ProductGoalProgress {
  product_goal_id, as_of,
  contribution_hypotheses[],
  evidence_for[], evidence_against[],
  environmental_changes[],
  unknowns[], risks[],
  current_interpretation,
  options[], next_learning_needed,
  owner_and_review_date
}

رنگ سبز/قرمز بدون Evidence/Unknown و Rule کافی نیست. Review می‌تواند نشان دهد Increment Done است ولی فرض Product Goal هنوز شاهد میدانی ندارد. Done دربارهٔ کیفیت Increment طبق DoD است؛ Outcome/Value پرسش دیگری است.

تغییر محیط را ورودی اصلی Review کنید

Change	پرسش	Adaptation ممکن
نیاز/Workflow ذی‌نفع	Outcome فعلی هنوز مناسب است؟	Refine Goal/PBI
رقیب/بازار	فرض ارزش تغییر کرده؟	Reorder/Experiment
Policy/constraint	چه شرط تازه‌ای لازم است؟	Risk/obligation
Production signal	Behavior واقعی با Lab فرق دارد؟	Observe/fix/test
Support pattern	کدام ambiguity تکرار شده؟	UX/diagnostic candidate
Technology/dependency	Feasibility/cost تغییر کرده؟	Option/architecture spike

Stakeholder را بر اساس تصمیم و Context انتخاب کنید

Context	دانش/تصمیم	Blind spot
End user/representative	Workflow و language	نمونهٔ محدود
Support	خطا/diagnostic/recovery	تمرکز روی موارد مشکل‌دار
Operations	deploy/observe/recover	Outcome کسب‌وکار
Finance/domain	Rule/reconciliation/unit	Interaction
Security/privacy/legal	constraint/risk/authority	Value/flow
Sales/market	need/positioning	representativeness
Product leadership	Goal/options/trade-off	جزئیات اجرا

حضور «همه» یا فقط Product Owner هر دو می‌تواند Feedback را محدود کند. Stakeholder map را با Product Goal و تصمیم Review تطبیق دهید؛ عدم حضور Perspective مهم را به Unknown تبدیل کنید.

Feedback رأی Approval نیست

ReviewFeedback {
  feedback_id, review_id,
  stakeholder_context,
  observed_at, increment_id,
  observation, expected_or_need,
  affected_outcome_or_goal_ref,
  consequence_or_opportunity,
  evidence_or_example_refs[],
  confidence_and_limits,
  type, disposition,
  decision_ref, backlog_change_ref
}

«دوست داشتم/تأیید» اطلاعات کمی دارد. بپرسید: در چه Workflow و برای چه Outcome؟ چه چیزی مشاهده شد؟ انتظار چه بود؟ پیامد چیست؟ Feedback می‌تواند Finding، Question، Need، Opportunity، Constraint، Risk signal یا Hypothesis باشد.

بازخورد مبهم را بدون هدایت پاسخ تبدیل کنید

عبارت	سؤال خنثی	خطر سؤال هدایت‌گر
این را دوست ندارم	در کدام کار/مرحله چه چیزی مانع شد؟	پس رنگ دکمه بد است؟
خیلی کند است	کدام Task، Context و انتظار زمانی؟	۲ ثانیه خوب است؟
عالی است	کدام Outcome بهتر شد و چه شاهدی دیدید؟	پس Approve می‌کنید؟
این لازم نیست	برای کدام نقش/Workflow و چه جایگزینی؟	حذفش کنیم؟
باید مثل قبل باشد	کدام رفتار قبلی و چرا ارزش داشت؟	پس Rollback؟

Feedback Triage و Disposition

Disposition	معنا	رکورد
ACCEPT_AS_CANDIDATE	نیازمند refinement/order است	Backlog candidate ID
QUESTION	اطلاعات برای تصمیم کافی نیست	Owner/Due
EXPERIMENT	فرض نیازمند شاهد است	Hypothesis/measure/guardrail
DEFECT	Observation به Defect workflow می‌رود	Defect ID
DUPLICATE	Feedback canonical وجود دارد	Canonical ID
DECLINE	در Product Goal/constraint فعلی دنبال نمی‌شود	Rationale/authority
DEFER	بعداً با trigger/expiry بررسی می‌شود	Target/review date
NO_CHANGE	Evidence جهت فعلی را پشتیبانی می‌کند	Decision rationale

ثبت هر نظر به‌عنوان PBI، Backlog را به Inbox بی‌مالک تبدیل می‌کند. Product Owner پاسخ‌گویی مدیریت مؤثر Product Backlog را حفظ می‌کند؛ Feedback input است، Order تصمیم Product است.

Adaptation Record قابل‌پیگیری

ReviewAdaptation {
  adaptation_id,
  observation_and_evidence_refs[],
  product_goal_or_outcome_ref,
  options_considered[], tradeoffs[],
  decision, decision_authority,
  owner, due_or_review_at,
  product_backlog_change_ref,
  next_evidence_needed,
  assumptions_and_unknowns[]
}

«در Sprint بعد اضافه شود» Adaptation کامل نیست. تصمیم ممکن است Reorder، Refine، Split، Experiment، Stop، Continue، Goal review یا No change باشد. هرکدام باید به Evidence/Feedback و Backlog/Decision record متصل شوند.

Risk و Unknown را به زبان تصمیم ترجمه کنید

گزارش فنی	Claim تصمیمی محدود
Load test در ۱۰۰ کاربر کند شد	در workload/env W1، p95 از threshold قراردادی گذشت؛ Production capacity نامعلوم؛ گزینه‌ها…
Security تست شد	Scope/threat/Build مشخص؛ Findings و خارج از Scope…
Regression پاس شد	Registry R17/Build B17؛ Evidence obligations پذیرفته و Gapها…
UX خوب است	در Task/participants/context مشخص، Observation و limitation…
هیچ باگ بحرانی نداریم	در cutoff و defect population تعریف‌شده، مورد State/Severity X نیست؛ Unknown…

برای ساخت Presentation شواهدمحور، راهنمای ارائه نتایج تست را ببینید. Sprint Review فقط آن بخش از Evidence را مصرف می‌کند که Outcome/Product direction را قابل بازرسی می‌کند.

Defect در Sprint Review: نه پنهان، نه Triage کامل

اگر Defect روی Outcome، Increment، Product Goal یا تصمیم آینده اثر دارد، پنهان‌کردن آن برای «خراب‌نشدن Demo» ضدشفافیت است. Observation و اثر را کوتاه و دقیق بگویید؛ Triage، Root cause و Workflow رفع را در مسیر مدیریت نقص ادامه دهید. هر Defect لازم نیست زمان Review را بگیرد.

UAT و Sprint Review را یکی نکنید

بعد	Sprint Review	UAT نمونه
هدف	Outcome inspection و future adaptation	پذیرش در برابر criteria/context
Cadence	هر Sprint	طبق Release/contract/process
Authority	همکاری Product؛ رأی رسمی ذاتی نیست	Acceptance authority ممکن است باشد
Environment/data	Increment قابل استفاده و context مناسب	UAT contract
خروجی	Feedback/options/Backlog adaptation	accept/reject/conditions/evidence
Release	Gate نیست	ممکن است ورودی Gate باشد

آمادگی Review: Evidence Pack، نه اسکریپت نمایشی

Product Goal/Sprint Goal و سؤال‌های Outcome مشخص‌اند؛
Increment/Build/DoD و Done items دقیق‌اند؛
Environment/Data/Fake و محدودیت fidelity روشن‌اند؛
Stakeholder Contextهای لازم دعوت شده‌اند؛
مسیرهای تعاملی و failureهای تصمیم‌ساز آماده‌اند؛
Evidence/Unknown/Risk به Claimهای محدود متصل است؛
WIP/Prototype جدا و برچسب‌دار است؛
Feedback schema و Recorder آماده است؛
Decision/Backlog update path معلوم است؛
Fallback برای failure دمو، بدون جعل Outcome وجود دارد.

Failure دمو را چگونه مدیریت کنیم؟

رخداد	پاسخ سالم	پاسخ ناسالم
Environment down	Impact/Unknown؛ recording با Build صریح؛ Follow-up	Slide را Increment جا زدن
Unexpected failure	Observation؛ containment؛ effect on claim	پنهان/Retry تا سبز شود
Data mismatch	Snapshot/lineage check؛ Claim معلق	دادهٔ واقعی اضطراری
Stakeholder absent	Perspective gap به Unknown؛ async follow-up	PO را نمایندهٔ همه فرض کردن
Time expires	اولویت Outcome/decision؛ remaining record	حذف Feedback و فقط Demo
Sensitive finding	Sanitized impact؛ restricted follow-up	افشای جزئیات

آزمایش تکرارپذیر: Demo موفق و چهار Approval

Fixture کاملاً ساختگی SYN-SPRINT-REVIEW-OUTCOME-01 چهار گام Demo را بدون خطا اجرا می‌کند و چهار رأی `approve` دارد؛ کنترل سطحی `PASS` می‌دهد. ممیزی Contract سپس Product/Sprint Goal، Increment/Build/DoD، Backlog/Environment، Done items، Evidence، limitation، Feedback و Adaptation را بررسی می‌کند.

Draft ساختگی آزمایش

بعد	Contract	Draft
Product/Sprint Goal	PG-9/SG-17	PG-8/SG-16
Increment/Build	INC-B17-DONE/B17	DEMO-B16/B16
DoD/Backlog/Environment	v4/PB18/ENV7	v3/PB16/ENV5
Items	P1/P2/P3 Done	P1/P2/P2/P4-WIP
Evidence	Functional/Idempotency/Reconciliation/A11Y	فقط IDemp B16
Limitations	برای هر Claim	همه خالی
Feedback	Context/Observation/Goal/Disposition	دو FB-۱ ناقص
Goal progress	Evidence + Unknown	GREEN بدون هردو
Adaptation	Owner/Decision/Backlog ref	«بعداً feature اضافه شود»

خروجی واقعی Fixture

fixture: SYN-SPRINT-REVIEW-OUTCOME-01
superficial: PASS | demoSteps=4 | approvals=4

auditedDraft: HOLD
findings (31):
1 wrong-product-goal:PG-8->PG-9
2 wrong-sprint-goal:SG-16->SG-17
3 wrong-increment:DEMO-B16->INC-B17-DONE
4 wrong-build:B16->B17
5 stale-dod:DOD-v3->DOD-v4
6 stale-backlog:PB-SNAP-16->PB-SNAP-18
7 stale-environment:ENV-LAB-5->ENV-LAB-7
8 missing-outcome-contribution:P1
9 missing-evidence:P1:EV-FUNCTIONAL-B17
10 limitations-omitted:P1
11 missing-evidence:P2:EV-IDEMP-B17
12 missing-evidence:P2:EV-RECON-B17
13 limitations-omitted:P2
14 duplicate-demo-item:P2
15 missing-evidence:P2:EV-IDEMP-B17
16 missing-evidence:P2:EV-RECON-B17
17 limitations-omitted:P2
18 non-done-item-presented-as-increment:P4-WIP
19 missing-outcome-contribution:P4-WIP
20 limitations-omitted:P4-WIP
21 feedback-missing-context:FB-1
22 feedback-missing-observation:FB-1
23 feedback-missing-goal-or-outcome-ref:FB-1
24 feedback-missing-disposition:FB-1
25 duplicate-feedback-id:FB-1
26 feedback-missing-goal-or-outcome-ref:FB-1
27 feedback-missing-disposition:FB-1
28 product-goal-progress-without-evidence
29 product-goal-progress-unknowns-omitted
30 environment-changes-omitted
31 adaptation-missing-owner-decision-or-backlog-ref

corrected: READY_FOR_REVIEW_OUTCOME_ADAPTATION | findings=0

نسخهٔ اصلاحی و مرز نتیجه

نسخهٔ اصلاحی PG-۹/SG-۱۷/INC-B17-DONE/B17/DOD-v4/PB18/ENV7 را قفل کرد؛ P1/P2/P3 را با Contribution، Evidence و limitation نمایش داد؛ دو Feedback یکتا از Support و Finance با Observation/Goal/Disposition ثبت کرد؛ Product Goal را `PARTIAL_EVIDENCE` با دو Unknown اعلام و دو Adaptation را به Product Owner، Decision و Backlog change وصل کرد. نتیجه فقط `READY_FOR_REVIEW_OUTCOME_ADAPTATION` است.

همهٔ Goal/Increment/Build/PBI/Evidence/Feedback/نقش و رأی‌ها ساختگی‌اند.
Fixture حقیقت یا کفایت Evidence، Value، کیفیت یا Product Goal progress را نمی‌سنجد.
چهار Approval رأی معتبر بازار، UAT یا Authority نیست.
۳۱ Finding معیار عملکرد تیم، Tester یا Review نیست.
خروجی Acceptance، Release، Risk acceptance یا compliance proof نیست.

سناریوی ایرانی کاملاً ساختگی: Review Checkout آفلاین

یک محصول خیالی Checkout در Lab قطع از شبکه مرور می‌شود. Increment B17 شامل مسیر پایه، Retry/Reconciliation جعلی و Interaction محدود است. اجزا Order، PaymentAttempt، PSP Stub جعلی، Callback، Ledger آزمایشی، Reconciliation و Notification fake هستند. هیچ بانک، PSP، کاربر، پول، تراکنش یا Production واقعی وجود ندارد.

Outcome سؤال	Interaction/Evidence	Limitation	Feedback Context
آیا retry ambiguity کم شده؟	P2 + EV-IDEMP/REC B17	PSP fake و Lab آفلاین	Support
آیا Ledger قابل فهم است؟	IRR-labeled reconciliation	هیچ settlement واقعی	Finance
آیا Interaction قابل استفاده است؟	keyboard/semantic evidence	Sample/AT coverage محدود	Accessibility
آیا Goal اثبات شد؟	Partial evidence	Production/user outcome Unknown	Product

هویت، مبلغ، Unicode و زمان در Review Lab

Tenant، Order، Attempt، Callback event، Ledger entry، Run، Build و Evidence ID مستقل‌اند.
مبلغ canonical فقط IRR ساختگی است؛ تومان فقط View برچسب‌دار است.
اعداد فارسی «۱۲۵۰۰۰»، عربی «۱۲۵۰۰۰» و لاتین «۱۲۵۰۰۰» synthetic هستند.
Instantها UTC/ISO ۸۶۰۱، View با Asia/Tehran و جلالی فقط Presentation است.
Timeout-before/after-fake-commit، retry، duplicate، late و reorder جدا هستند.
نام، موبایل، ایمیل، IP، حساب، کارت، PAN، CVV2، OTP، Cookie، Token، Secret، Log و Screenshot واقعی ممنوع‌اند.

این Lab توصیهٔ بانکی، مالی، حقوقی، مالیاتی، امنیتی، حریم خصوصی یا تحریمی دربارهٔ ایران نیست و رفتار هیچ PSP/بازار/کاربر واقعی را نمایندگی نمی‌کند.

Review Brief نمونه

Review: SYN-REV-17 | Increment: INC-B17-DONE | DoD v4
Product Goal: PG-9 | Sprint Goal: SG-17 | Environment: ENV-LAB-7

Outcome questions:
1) آیا recovery status ابهام Support را کم می‌کند؟
2) آیا Reconciliation با واحد صریح قابل فهم است؟

Evidence:
- Functional/Idempotency/Reconciliation/A11Y روی B17
- محدودیت: Lab آفلاین، PSP fake، بدون Production/user inference

Feedback:
- FB-1 Support: reason code اپراتوری غایب → Backlog candidate
- FB-2 Finance: export نیازمند برچسب IRR → Backlog candidate

Product Goal: PARTIAL_EVIDENCE
Unknown: توزیع Callback واقعی؛ فهم کاربران نماینده

Adaptations:
- DEC-1/PB-CHANGE-1: refine reason-code candidate
- DEC-2/PB-CHANGE-2: explicit IRR label candidate

Remote/Hybrid Sprint Review

Increment interactive و keyboard-accessible باشد، نه فقط Screen share؛
Caption، description و مسیر متن برای Evidence بصری فراهم شود؛
Timezone و Context Stakeholder ثبت شود؛
Feedback async به همان Increment/Build/Question وصل شود؛
Breakout فقط با سؤال/Outcome و Merge record؛
رأی emoji جای Observation/Disposition را نگیرد؛
Recording با consent/access/retention و Build ID باشد؛
تصمیم‌ها در Product Backlog canonical همگام شوند.

امنیت و حریم خصوصی Review

ریسک	کنترل	جایگزین
Demo با Production data	منع/approval/redaction	synthetic dataset
نمایش Token/Log	pre-review scan	sanitized evidence ref
Security finding	need-to-know	impact summary + restricted follow-up
Recording	consent/access/expiry	decision notes
Stakeholder identity	minimization	role/context code
Feedback sensitivity	classification	restricted record
External AI/tool	approved data route	local/synthetic input

هوش مصنوعی در Sprint Review

کار	استفادهٔ محدود	Gate
Review brief	Draft از Source IDs	Increment/Build/Evidence check
Feedback capture	Transcript→candidate records	Stakeholder confirmation
Theme clustering	Candidate duplicate/theme	minority/context preservation
Question generation	Outcome prompts	non-leading review
Adaptation options	Candidate trade-offs	Product Owner/team decision
Summary	Draft decision/backlog changes	canonical records

مدل ممکن است Feedback اقلیت را حذف، رأی را Consensus، WIP را Done، هم‌بستگی را علت یا Risk را قطعی کند. Model/version، Prompt، Source، خروجی خام و اصلاح انسانی را ثبت کنید. AI نمی‌تواند Stakeholder context، Product accountability یا Evidence را جایگزین کند.

نقش‌ها و حق تصمیم

نقش/قابلیت	در Review	مرز
Scrum Team	Increment/Outcome/learning را بازرسی می‌کند	Demo team جدا ندارد
Product Owner	Product Goal/Backlog/value accountability	تنها تولیدکننده Feedback نیست
Developers	Increment و همهٔ قابلیت‌های لازم را نمایندگی می‌کنند	فقط ارائهٔ فنی نیست
Testing capability	Evidence/limits/risk/unknown	QA sign-off یا کیفیت‌قهرمانی نیست
Stakeholders	Context/observation/need/change	رأی جمعی Release نیست
Recorder/facilitator	Feedback/Decision/Adaptation lineage	Order/authority را تصاحب نمی‌کند
Release/UAT authority	در فرایند جدا تصمیم می‌گیرد	به‌طور ذاتی Review participant نیست

برای مالکیت مشترک بدون ابهام، راهنمای رهبری تضمین کیفیت را ببینید. Review باید Perspectiveهای مختلف را به تصمیم متصل کند، نه یک فرد را سخنگوی کیفیت سازد.

Metricهای سلامت Review و Countermetricها

Metric	تعریف محدود	Countermetric
Stakeholder context coverage	Contextهای لازم حاضر/کل	representativeness/depth
Interaction ratio	زمان کار/گفت‌وگو نسبت به ارائه	decision quality
Feedback traceability	Feedbackهای با Increment/Context/Goal	novelty/value
Disposition latency	Feedback تا decision	premature decisions
Adaptation closure	Backlog changes با Owner/decision	outcome realized
Unknown aging	سن Unknownهای Goal	forced certainty
Evidence correction	Claimهای تصحیح‌شده	under-reporting
Demo failure recovery	زمان/کیفیت response	concealment
Attendance	Contextهای حاضر	engagement/relevance
Review duration	زمان Working session	learning/decision outcome

تعداد Feedback، Attendance یا Backlog item را KPI فردی نکنید. تیم می‌تواند Feedback کم اما مهم یا تصمیم No-change داشته باشد. Metric برای بهبود حلقه است، نه اثبات ارزش Tester یا Review.

ضدالگوهای نقش تستر در Sprint Review

تستر به‌عنوان قهرمان/صدای انحصاری کیفیت؛
Developer فقط Happy path و Tester فقط edge case؛
QA demo جدا از Increment؛
Sign-off تستر برای Done؛
Review به‌عنوان UAT یا Release gate؛
نمایش WIP/Prototype به‌عنوان Increment؛
Build/DoD/Data/Environment نامعلوم؛
Script بی‌خطا به‌عنوان Evidence Value؛
۲۰۰ تست/۸۵٪ Coverage به‌عنوان عدم Regression؛
رنگ سبز Product Goal بدون Evidence/Unknown؛
پنهان‌کردن Defect برای حفظ Demo؛
Triage کامل Defect در Review؛
Feedback به شکل رأی/emoji/«دوست داشتم»؛
PO به‌عنوان نمایندهٔ همهٔ کاربران؛
دعوت همه بدون Stakeholder context؛
پرسش‌های هدایت‌گر برای گرفتن Approval؛
هر Feedback مساوی PBI؛
Backlog candidate بدون Disposition/Owner؛
Adaptation «Sprint بعد» بدون Decision/ref؛
Slide/recording جای Increment؛
دادهٔ Production/Token در Demo؛
AI summary که Feedback اقلیت را حذف می‌کند؛
Metric Attendance/Feedback برای ارزیابی فرد؛
عدم تغییر از پیش تعیین‌شدهٔ Product Backlog؛
ادعای Trust/quality/value/release از Review.

Pilot سی‌روزه برای Outcome Review

بازه	کار	خروجی
روز ۱–۵	مشاهدهٔ Review فعلی: presentation/interaction/feedback/adaptation	Baseline
روز ۶–۱۰	تعریف Increment/Outcome/Evidence/Feedback contracts	Template v0.1
روز ۱۱–۱۵	Fixture synthetic و تمرین WIP/Build/feedback mismatch	Executable audit
روز ۱۶–۲۰	یک Review shadow با Outcome questions	Gap/learning log
روز ۲۱–۲۴	تمرین demo failure، absent stakeholder و No-change	Recovery evidence
روز ۲۵–۲۷	Remote/accessibility/privacy/AI review	Approved route
روز ۲۸–۲۹	Metric+Countermetric و مصاحبه ذی‌نفع	Trade-off report
روز ۳۰	Adopt/Adapt/Stop و rollback	Decision record

چک‌لیست Sprint Review شواهدمحور

Product Goal و Sprint Goal دقیق‌اند.
Increment ID/Build/DoD و Facts-as-of ثبت شده‌اند.
فقط Done واقعی به‌عنوان Increment نمایش داده می‌شود.
WIP/Prototype/Fake/recording برچسب و limitation دارد.
Product Backlog و Environment snapshot تازه است.
Outcome questions پیش از Demo روشن‌اند.
هر item Contribution به Outcome/Goal دارد.
Evidence به Build/Data/Environment/Oracle متصل است.
Evidence for/against و Unknown نمایش داده می‌شود.
Counterclaim و explicitly-not-proven روشن است.
Product Goal progress از Done جداست.
Environment changes بررسی شده‌اند.
Stakeholder contexts با تصمیم تناسب دارند.
Perspective غایب به Unknown تبدیل شده است.
Interaction واقعی یا نزدیک به Context فراهم است.
Demo script Feedback را هدایت نمی‌کند.
Failure/edge فقط وقتی تصمیم‌ساز است نمایش داده می‌شود.
Feedback ID/Context/Observation/Goal ref دارد.
Question/Need/Risk/Defect/Opportunity تفکیک می‌شوند.
رأی/emoji جای Feedback record نیست.
هر Feedback Disposition/rationale می‌گیرد.
Backlog candidate با Product Owner/Order اشتباه نمی‌شود.
Options و trade-offs ثبت می‌شوند.
Adaptation Owner/Decision/Backlog ref دارد.
No-change نیز rationale دارد.
UAT/Release/Risk acceptance جدا هستند.
Defect اثرگذار شفاف ولی Triage جداست.
Demo data/recording/AI مسیر امن دارند.
Metricها Countermetric و Context دارند.
نتیجه ادعای کیفیت/ارزش/بازار/Release جهانی نمی‌کند.

مسیر مطالعهٔ مرتبط

Sprint Planning شواهدمحور: Goal/Risk/Evidence آغاز Sprint؛
Daily Scrum شواهدمحور: Plan adaptation روزانه؛
ارائه نتایج تست: Evidence/claim/decision؛
UAT: پذیرش کاربر و Authority؛
گزارش تست و تصمیم انتشار: Release packet؛
مدیریت نقص: Triage/Closure؛
رهبری تضمین کیفیت: Ownership/Authority.

سؤالات متداول درباره نقش تستر در Sprint Review

۱. آیا تستر باید Demo را اجرا کند؟

Scrum نقش Presenter ثابت تعیین نمی‌کند. هر فردی از Scrum Team که بهترین Context را برای Interaction دارد می‌تواند تسهیل کند؛ بهتر است Demo «Developer versus Tester» نباشد. قابلیت تست روی Evidence، Risk و limitation کمک می‌کند، اما Demo جداگانهٔ QA یا اجرای نمایشی edge case الزام نیست.

۲. آیا Sprint Review جلسه تأیید Done یا UAT است؟

خیر. فقط Work مطابق DoD بخشی از Increment است و این واقعیت باید پیش از Review شفاف باشد. Review Outcome و Product direction را با ذی‌نفعان بازرسی می‌کند؛ UAT یا Sign-off ممکن است Contract، Environment، Criteria و Authority جدا داشته باشد. Review نیز Gate انتشار نیست.

۳. باگ و ریسک را در Sprint Review مطرح کنیم؟

اگر بر Outcome، Increment، Product Goal یا تصمیم بعدی اثر دارد، Observation و اثر را شفاف و محدود مطرح کنید؛ پنهان‌کردن برای حفظ Demo درست نیست. جزئیات Triage/Root cause را به Defect workflow ببرید. هر Bug کم‌اثر یا Log فنی لازم نیست Timebox Review را مصرف کند.

۴. چگونه Feedback مبهم ذی‌نفع را قابل‌اقدام کنیم؟

بدون هدایت پاسخ بپرسید: در کدام Workflow/Context چه چیزی مشاهده شد؟ انتظار یا Need چه بود؟ کدام Outcome/Product Goal متاثر می‌شود؟ مثال چیست و چه محدودیتی دارد؟ سپس Feedback را Question، Need، Risk، Defect، Opportunity یا Hypothesis طبقه‌بندی و Disposition/Decision/Backlog ref ثبت کنید.

۵. آیا رأی تأیید ذی‌نفعان برای انتشار کافی است؟

خیر. رأی در Demo نه نمایندگی بازار را تضمین می‌کند، نه UAT/ریسک/عملیات/امنیت را پوشش می‌دهد و نه Authority انتشار می‌سازد. Release decision باید طبق Governance و Evidence packet خود انجام شود. Sprint Review می‌تواند ورودی مهم بدهد، اما خودش Gate انتشار نیست.

جمع‌بندی: از Demo به Outcome Adaptation

مشارکت مؤثر قابلیت تست در Sprint Review با اجرای edge case یا نمایش تعداد تست‌ها تعریف نمی‌شود. Increment Done و Build واقعی را قابل تعامل کنید؛ Evidence و Unknown را به Outcome/Product Goal وصل کنید؛ محدودیت استنتاج را پنهان نکنید؛ Feedback را با Context و Observation ثبت کنید؛ و آن را به گزینه، تصمیم و Product Backlog change تبدیل کنید. Review زمانی ارزش دارد که محصول و محیط را صادقانه قابل بازرسی و جهت آینده را قابل سازگاری کند—بدون قهرمان‌سازی QA، UAT نمایشی یا وعدهٔ کیفیت و Release.

مدیریت تست

نقش تستر در Sprint Review؛ از Demo تا Outcome Adaptation