Work items
How Skopo models the units of work, their fields, identity, and relations.
Work items are the atomic units of delivery in Skopo. Every task, story, bug, pitch, or experiment is a work item. The types available in a project, and the fields each type carries, come from the active methodology configuration.
Types and fields
Each methodology defines its own set of work-item types. Scrum projects have epics, stories, bugs, tasks, and spikes. Kanban projects have requests, features, bugs, tasks, and expedite items. Shape Up projects have raw ideas, pitches, bets, scopes, and tasks. The types appropriate for the methodology are the only ones available in that project.
Each type carries a set of fields. All types share a title, description, and status. Additional fields — estimates, priority, tags, acceptance criteria, assignee, and any methodology-specific custom fields — appear when the active methodology definition includes them. Fields are rendered from the project's configuration snapshot, so they remain stable until you apply a methodology upgrade.
Stable identity
Work items keep the same identifier for their entire lifetime in Skopo. Type remappings and methodology migrations may change an item's type label or workflow state, but they never change its numeric ID or its history. Comments, assignments, policy checks, linked goals, risks, and decisions all reference the item by that stable ID.
This means you can safely switch methodology, apply an upgrade, or rename a status without breaking cross-references, audit records, or links embedded in external tools.
Relations
Work items support two kinds of relation:
Hierarchy. Types within a methodology form a parent-child tree. In Scrum, epics are parents of stories, bugs, tasks, and spikes. In Dual-Track Agile, an opportunity can contain assumptions, experiments, insights, and stories. The methodology definition describes which types can nest under which other types, and the board and backlog respect that hierarchy.
Cross-item links. Work items can be linked to project goals, risks, decisions, and dependencies through the Operations and Delivery views. A work item can also block or be blocked by another item, and those blocking relationships surface on board cards and in ritual candidate work.