Methodologies

A methodology in Skopo is not a theme or a label. It is a versioned configuration that determines every structural aspect of a project: the work-item types available, the workflow states and their rules, the rituals the team runs, the artifacts they maintain, the quality policies applied, and the metrics tracked. Changing the methodology changes all of these together.

Methodology as configuration

All methodologies run on the same rendering engines. The board, the Rituals page, the Insights view, and the Delivery workspace are shared infrastructure that reads the active project configuration. A Scrum project and a Kanban project open the same board engine — they just receive different column definitions, WIP rules, and transition rules from their methodology configuration.

This means the difference between methodologies is precise and auditable. You can inspect exactly which work-item types, workflow states, and policies a project uses, and compare them across methodology versions.

One base methodology plus practices

Each project has exactly one base methodology — Scrum, Kanban, Shape Up, Extreme Programming, Scrumban, Dual-Track Agile, or Basic. The base methodology sets the structural defaults: item types, workflow, rituals, artifacts, and metrics.

On top of the base, you can enable optional practices in the project's Settings. Practices are add-ons that modify or extend the base without replacing it. For example, a Scrum project can adopt TDD, pair programming, or continuous integration from XP's practice catalogue. A Kanban project can enable classes of service or an explicit expedite policy.

Practices are selected per project and stored as part of the project's configuration snapshot, so two projects on the same base methodology can run different practice combinations.

Versioned snapshots

When a project is created, Skopo writes a resolved configuration snapshot — the full set of definitions at the time of creation. The project then runs against that snapshot, not the live catalog definition.

This means catalog updates do not silently change existing projects. If a new version of a methodology is published, you see an upgrade prompt and decide explicitly whether to apply it. The upgrade shows what will change before anything is written.

Custom methodology templates published by your organisation work the same way: projects opt into each published version through the same migration path used for built-in templates.

Switching is a migration

Switching a project from one base methodology to another is an explicit two-step process. First, Skopo shows a preview: which work-item types will be remapped, how workflow states will be translated, which artifacts or policies are new or removed, and what metric history will carry forward.

After you review the preview, you apply the migration. The migration writes the new configuration snapshot, remaps existing work items and states, preserves all item identities and history, backfills any required policy checks, and records an attributable event. Nothing changes until you explicitly confirm the apply step.

For more detail on what each methodology provides, see the Methodologies section.