---
title: "Scrum4Me — Glossary"
status: active
audience: [ai-agent, contributor]
language: en
last_updated: 2026-05-08
when_to_read: "When you encounter a domain term and need its canonical definition and the doc where it is specified."
---

# Scrum4Me — Glossary

Domain terms used across Scrum4Me docs, code, and MCP tooling.

## agent worker

A Claude Code session that has registered itself as a `ClaudeWorker` record and polls the job queue via `mcp__scrum4me__wait_for_job`. The NavBar counts active workers by `last_seen_at < now() - 15s`. See [MCP integration runbook](./runbooks/mcp-integration.md).

## ClaudeJob

A row in the `claude_jobs` table — the queue from which agents claim work atomically (`FOR UPDATE SKIP LOCKED`). Distinguished by `kind` (`TASK_IMPLEMENTATION`, `IDEA_GRILL`, `IDEA_MAKE_PLAN`, `PLAN_CHAT`, `SPRINT_IMPLEMENTATION`) and tracked through `status` (`QUEUED → CLAIMED → RUNNING → DONE/FAILED/CANCELLED/SKIPPED`). See [data-model](./architecture/data-model.md) and [MCP integration runbook](./runbooks/mcp-integration.md).

## claude-question

A pending question posted by an agent (via `mcp__scrum4me__ask_user_question`) to a human user, stored in the `claude_questions` table. The user answers in the UI; a PostgreSQL `LISTEN/NOTIFY` trigger pushes the answer back to the waiting agent. See [architecture: claude-question-channel](./architecture/claude-question-channel.md) and [ADR-0007](./adr/0007-claude-question-channel-design.md).

## demo-token

An API token whose owning user has `isDemo = true`. All write operations are blocked at three layers: the `proxy.ts` middleware, individual server actions, and disabled UI buttons. See [architecture: auth and sessions](./architecture/auth-and-sessions.md) and [ADR-0006](./adr/0006-demo-user-three-layer-policy.md).

## demo-user

A preconfigured read-only account used for public showcase. Shares product data with the main account but cannot create, update, or delete anything. See [architecture: auth and sessions](./architecture/auth-and-sessions.md).

## Idea

A user-scoped idea captured before it becomes a PBI. An idea is first _grilled_ via an interactive Q&A loop (`IDEA_GRILL` job → `grill_md`), then materialized through a deterministic plan (`IDEA_MAKE_PLAN` job → `plan_md`) into a PBI with stories and tasks. Replaced the legacy `todos` table in M12. Status enum: `DRAFT | GRILLING | GRILL_FAILED | GRILLED | PLANNING | PLAN_FAILED | PLAN_READY | PLANNED`. See [data-model](./architecture/data-model.md) and the [M12 plan](./plans/M12-ideas.md).

## MCP-job

Synonym for **ClaudeJob** — used in agent-facing docs because Claude Code consumes the queue through MCP tools. An agent claims a job atomically via `mcp__scrum4me__wait_for_job` and reports completion via `mcp__scrum4me__update_job_status`. See [MCP integration runbook](./runbooks/mcp-integration.md).

## PBI (Product Backlog Item)

The second level of the work hierarchy: `Product → PBI → Story → Task`. A PBI groups related stories under a single theme or capability. Status enum: `READY | BLOCKED | FAILED | DONE`. Has a stable `code` (`PBI-N`) per product. Do not use "Epic", "Feature", or "Issue" as synonyms.

## Solo Panel

The single-user planning screen that shows all PBIs and stories for one product in a split-pane drag-and-drop layout. Contrast with the Sprint board (team-facing). See [functional spec — Solo Panel](./specs/functional.md).

## Sprint

A time-boxed iteration with a `sprint_goal` and a stable `code` (`SP-N`) per product. A product can hold multiple sprints simultaneously (PBI-63) — `OPEN` is not exclusive; the sprint-switcher in the product header lets the user pick which sprint to plan against. Status enum: `OPEN | CLOSED | ARCHIVED | FAILED`. Stories enter `IN_SPRINT` when added to a sprint via `sprint_id`. See [data-model](./architecture/data-model.md).

## SprintRun

A single execution of the SPRINT_IMPLEMENTATION flow against one Sprint. Tracked in `sprint_runs` with status `QUEUED | RUNNING | PAUSED | DONE | FAILED | CANCELLED`, optional `pause_context` for resume, and a chain via `previous_run_id` for retries. The frozen scope-snapshot per run lives in `sprint_task_executions`. See [sprint execution modes](./architecture/sprint-execution-modes.md).

## Story

The third level of the work hierarchy: `Product → PBI → Story → Task`. A Story has acceptance criteria, an optional `assignee_id` (Solo-bord claim), a stable `code` (`ST-N`) per product, and a status (`OPEN | IN_SPRINT | DONE | FAILED`). See [functional spec](./specs/functional.md).

## Task

The leaf level of the work hierarchy: `Product → PBI → Story → Task`. A Task has an `implementation_plan`, a stable `code` (`T-N`) per product, a `status` (`TO_DO | IN_PROGRESS | REVIEW | DONE | FAILED | EXCLUDED`), `verify_only` and `verify_required` flags, and an optional `repo_url` override. API exposes status as lowercase (`todo | in_progress | review | done | failed | excluded`). See [data-model](./architecture/data-model.md) and [ADR-0004](./adr/0004-status-enum-mapping.md).

## verify_result

The agent's outcome of a verification pass (`ALIGNED | PARTIAL | EMPTY | DIVERGENT`). Combined with the task's `verify_required` threshold (`ALIGNED | ALIGNED_OR_PARTIAL | ANY`) it determines whether a job's claim of "done" is accepted by the gate. See [agent-flow-pitfalls runbook](./runbooks/agent-flow-pitfalls.md).