The tables behind IT Projects PM

The agile project container — one row per product, service, or named initiative (e.g. “Auth Platform”, “Billing API”, “Internal IT — Onboarding Automation”). Carries the Key prefix that namespaces every Issue (AUTH, BILL, IT).

Sub-modules within a Project — auth-service, billing-api, web-ui, mobile-android. Issues are tagged with a Component for routing and per-area reporting.

The taxonomy of work-item kinds — Story, Bug, Task, Epic, subtask, Spike, Improvement, Incident. Each Project pairs an issue type with a Workflow.

The unit of work — Story, Bug, Task, Epic, subtask, Spike, Improvement, Incident. Carries the issue key (<ProjectKey>-<seq>), full state, sprint assignment, fix-version, parent-epic linkage, and the Estimate / Remaining for burndown.

The prioritized work pool per Project — Issues that are not yet on a Sprint. One Backlog header per Project; the Issues themselves remain in Issues with Sprint = null and a BacklogRank ordering.

Time-boxed iteration — one row per sprint per Project. Decomposes into a frozen sprint commitments snapshot at start.

Frozen snapshot of which Issues were on the Sprint at start, with the committed estimate / status / assignee at the moment of sprint-start. Append-only — the truth retros measure against.

Immutable per-issue closure observations frozen before rollover; historical velocity never reads a moved or reestimated current issue.

The unit of work — Story, Bug, Task, Epic, subtask, Spike, Improvement, Incident. Carries the issue key (<ProjectKey>-<seq>), full state, sprint assignment, fix-version, parent-epic linkage, and the Estimate / Remaining for burndown.

Per-Project per-Sprint velocity rollup — committed vs. completed points, carryover, and the trailing-3-sprint average used as suggested capacity for sprint planning.

Kanban or Scrum board per Project. A Project can have multiple Boards (one Scrum board per squad, plus a triage board, plus a release board).

The columns on a Board, mapped to one or more workflow statuses. Carries the per-column WIP limit enforced by the wip-limit-enforcement workflow.

The workflow statuses mapped to a board column — one row per status mapped into the column. Replaces a comma-separated list with structured rows so referential integrity holds.

Per-Board per-column WIP-limit override and history — admin-tunable without rewriting board columns. One row per Board × Column with the current effective limit and the change history pointer.

Issue-lifecycle workflow definitions — one row per Project per issue type (or a default “global” Project = null + issue type combo). Decomposes into structured workflow statuses and workflow transitions child rows.

The allowed status moves — A → B with optional gating predicate and optional approver requirement. The status-transition-routing workflow validates every Issue status change against this table.

Version-bound requests for a named workflow decision; the transition service consumes only a valid independent approval.

The unit of work — Story, Bug, Task, Epic, subtask, Spike, Improvement, Incident. Carries the issue key (<ProjectKey>-<seq>), full state, sprint assignment, fix-version, parent-epic linkage, and the Estimate / Remaining for burndown.

Typed dependency / relationship between two Issues. Append-only; deletion is via marking Inactive so audit history survives.

Threaded discussion on an Issue. Supports markdown, edit history via EditedAt, and resolution flagging on threads.

Files attached to an Issue — repro screenshots, log snippets, design specs.

Version-bound requests for a named workflow decision; the transition service consumes only a valid independent approval.

References to git pull requests linked to the Issue. Populated by the auto-link-to-pr webhook from GitHub / GitLab / Bitbucket.

Authenticated source event observations and delivery intent outcomes; provider acknowledgments do not supply business approval.

Release versions per Project (e.g. AUTH 2.4.0, BILL 2026.04). Issues carry FixVersion and AffectsVersion references against this table.

The unit of work — Story, Bug, Task, Epic, subtask, Spike, Improvement, Incident. Carries the issue key (<ProjectKey>-<seq>), full state, sprint assignment, fix-version, parent-epic linkage, and the Estimate / Remaining for burndown.

Free-form text labels on an Issue (needs-design, tech-debt, released-2026-04). One row per label per Issue.

Large bodies of work that span multiple Sprints — first-class master even though IssueType=Epic Issues exist. The Epic record carries the rolled-up status and the link to all child Issues.

Derived per-Epic rollup — total / done / in-progress / backlog Issue counts and estimate sums. Recomputed by the issue status-transition workflow on every Issue change inside the Epic.

Non-version delivery checkpoints per Project (alpha cut, beta cut, GA, security review pass). Distinct from Versions, which retain reviewed release cuts; deployment needs separate external evidence.

Per-Sprint daily data points — the X / Y series feeding the Burndown chart. One row per Sprint per day from start date through end date.

Per-Project per-Sprint velocity rollup — committed vs. completed points, carryover, and the trailing-3-sprint average used as suggested capacity for sprint planning.

Immutable per-issue closure observations frozen before rollover; historical velocity never reads a moved or reestimated current issue.

The states a Workflow allows — to do, in progress, in review, Done, Blocked, Cancelled, plus any project-specific custom states. One row per state.

Per-Issue per-day time logged against the Issue. Feeds the remaining-estimate burndown and the Time Logged per-Sprint report. Not billing-grade — for billing flow, this exports to a pm-time / pm-billing app.

Append-only audit log of every change to an Issue — status transitions, assignee changes, estimate changes, sprint moves, field edits. Backs the Issue activity sidebar and the audit / who-did-what-when reporting.

Scoped application users mapped to authenticated platform principals.

Named delivery squads; team membership is explicit and scoped.

Active user-to-team relationship imported or approved by the workspace administrator.

Explicit project role grants including stakeholder and reporter audiences; team membership alone does not grant an administrative role.