defer-issue

You can track out-of-scope decisions during sprint planning by creating a deferred issue that enforces a six-field model, capturing Context, Options, Trigger Condition, Prerequisites, Gate Entry Point, and References to ensure reliable traceability and repeatable re-entry.

The structured deferral process for issue triage links valid but out-of-scope requirements to future slices when their Trigger Conditions are met at Gate 1, applying a label taxonomy and triage rules to manage the deferred work.

You can categorize deferred UX options and requirement gaps using a defined label taxonomy that includes deferred, ux, enhancement, and question labels, ensuring each deferral is properly sorted for future triage.

Yes, you need to fill all six required fields when deferring an issue because the fixed model enforces structured traceability and governance, ensuring the deferred decision has clear prerequisites and a defined gate entry point for future triage.

You should not use a structured deferral protocol for issue tracking when work is in scope for the current slice, as this protocol is specifically designed to capture valid but out-of-scope decisions, UX options, and requirement gaps for reliable future re-entry.

Yes, you can use this deferral approach to manage requirements gaps in your current sprint by capturing them as structured issues with trigger conditions and gate entry points, allowing your team to proceed while ensuring reliable tracking for future slices.