Policies and quality
How Skopo models quality policies, evidence, gates, and exceptions.
Skopo enforces the quality rules built into each methodology as explicit, inspectable policy checks rather than informal conventions. Policies describe what must be true before work can advance or be released. Evidence links, gate evaluations, and exception records are all persisted so the team can audit how quality decisions were made.
Policies and evidence
Each methodology ships with a set of policies appropriate to its way of working. Scrum requires that every sprint has one Sprint Goal and that work meets the Definition of Done before completion. Kanban requires that work is only pulled when capacity exists and that workflow policies are explicit. XP requires that production changes are tested first.
Policies become actionable at the work-item and release level through policy checks. A check asks whether the condition is satisfied and records the answer. Evidence for a check can be:
- an approved artifact (for example, a Sprint Goal artifact satisfies the Sprint Goal policy);
- a linked external URL, such as a GitHub pull request or a CI pipeline run;
- a manual attestation by an authorised team member.
The Delivery view shows all policy checks in a Quality gates tab, with current evidence status for each.
Gates
A gate is a policy check evaluated at a specific point in the workflow — typically at a state transition or as part of release readiness. When a work item attempts to move to a gated state, Skopo evaluates the relevant checks. If a blocking gate fails, the transition is prevented and the failing condition is shown on the board card, in the item detail drawer, and in ritual candidate work.
Advisory gates warn but do not block. They appear the same way but allow the transition to proceed.
Release readiness is a special gate evaluated across all active policy checks for the current release. The Delivery view shows whether release readiness is satisfied, and unresolved high-impact risks or active dependencies also block the final release gate.
Exceptions
When a policy check cannot be satisfied in the normal way, a team member with the appropriate role can create an authorised exception. An exception requires:
- a stated reason;
- review and approval by an owner or admin;
- an actor and timestamp for both the request and the review.
Active exceptions are visible alongside the policy check they override. Each exception records when it was created, who approved it, and whether it has been revoked. The exception audit history is retained indefinitely, so the team can understand why a quality gate was bypassed and who authorised it.
Transition-gate exceptions work the same way: a gate failure can be overridden by a recorded exception rather than a permanent policy change.