PlanWright
Planning Frameworks

Planning Frameworks

Planning Frameworks

Planwright is not a framework. It is infrastructure that works with the planning approach your team already uses — or that gets out of the way when your team has moved past frameworks entirely.

OKRs

Objectives & Key Results

Planwright's primitives map cleanly to OKR structure — without the grading ceremony.

In OKR terms: a Planwright Objective is the O — a clear, agent-executable outcome. An Initiative is a natural container for a cluster of Key Results, grouped by strategic theme. Strategic Focus (BUILD / GROW / TRUST / SCALE) provides the taxonomy that connects every objective to the organizational strategy without requiring manual OKR alignment sessions. What Planwright does not implement: scoring, grading, confidence ratings, or quarterly OKR reviews. Those processes are human rituals that live outside the board. Planwright tracks whether objectives were accepted or rejected, and how long they took — not whether the team gave the quarter a 0.7.

Outcome-driven planning

Jobs to be done

Planwright is built for outcome thinking. Every objective is an outcome statement — never a task list.

The discipline outcome-driven planning demands — write the outcome, not the solution — is enforced structurally in Planwright. Objectives are atomic outcome statements. They have no subtasks, no checklists, and no breakdown UI. If you find yourself writing subtasks inside an objective, you are writing agent instructions, not a human objective. Hand the decomposition to the agent: it posts a plan when it claims the work, and the plan lives in the audit trail, not on the board. The human stays at the outcome layer; the agent owns the how.

Agile and sprint-based teams

No sprints or velocity

Planwright has no sprints, story points, or velocity math. This is a design decision, not a missing feature.

Sprint planning assumes humans break work into tasks and estimate effort. Planwright assumes agents execute and report back. The cognitive overhead of estimation disappears when an agent can claim an objective, decompose it, ship it, and request review — often in the same session. For teams who still want time-boxed delivery: set a target date on an Initiative and use the initiative as a delivery batch. The accept/reject gate at the end of each objective is a natural review point without a sprint retrospective. Teams migrating from Jira or Linear can map their epics to Initiatives and their tickets to Objectives — but should resist the urge to recreate subtask hierarchies.

No story points. No velocity. No capacity math. If you need those, Planwright is not the right tool.

Strategic roadmapping

Portfolio view

Initiatives with target dates are the roadmap. Strategic Focus is the portfolio allocation view.

A Planwright roadmap is a list of Initiatives, each with a name, a description, a target date, and a set of Objectives. The Strategic Focus report shows how objectives are distributed across BUILD, GROW, TRUST, and SCALE — making underinvestment visible without a spreadsheet. Leaders who want a timeline get one without drawing it: the roadmap shows each initiative as a Gantt bar built from its objectives and target date, draws “blocked by” dependencies between initiatives, and forecasts when each will be accepted and done from observed agent run and review times, with what-if controls for agent and reviewer counts. Leaders who want a theme view can filter by Strategic Focus area. Neither view requires a dedicated roadmapping tool. What Planwright still avoids: story points and estimates. The forecast comes from how long work actually takes, not from anyone's guess.

Spec-driven development

Verified specs

Planwright keeps the spec and adds verification, so the agent's own report is never the only evidence that the spec held.

Spec-driven tools such as Spec Kit and Kiro get the order right: requirements, edge cases and project rules come before code. Most workflows stop at the spec — the agent reads it, writes code, says it is done, and the team trusts the agent's summary. Planwright keeps the spec and adds verification. Acceptance criteria include explicit error cases, written EARS-style when that helps: “IF the token is expired, THEN THE SYSTEM SHALL return 401.” Invariants capture project-wide rules such as “audit records are never modified” or “no query reads across workspaces”; the agent proposes them from your context files, a human approves each one, and every change that touches one has to pass its tests. Every criterion and invariant links to a real test in your repo, so you can see what is guarded and what is not. Results come from your own CI, not just the agent's report, and when the agent and CI disagree, the reviewer sees both. At the strictest verification level, tests are written and locked before the code, and they have to fail first. Every approval is recorded in the signed, tamper-evident audit trail.

Planwright doesn't generate tasks from the spec or run your code. Your agent does the breakdown and the work; Planwright tells it what must hold and checks the evidence.

The native model

Regardless of which framework you bring, Planwright's primitives stay the same. The board is flat: Objectives move through lanes, grouped optionally into Initiatives, classified by Strategic Focus. There is no parallel hierarchy for frameworks to hook into.

Objectives

Atomic outcome statements. Drafted by an agent, approved by a human. Executed by agents. No subtasks.

Initiatives

Named delivery batches with a target date. Optional — not every objective needs one.

Lanes

Proposed → Backlog → Scheduled → In Progress → Acceptance → Done → Released. Agents can't self-approve.