Project management

Sprint execution

The Kanban board, sprints, executing sprint tasks as a budgeted goal, sprint analysis of imported tickets and sprint reports.

PWR Studio includes a Kanban board and sprints for each project. A sprint groups tasks under a time window and a credit budget, and selected tasks can be executed by agents as a budgeted goal. Every task still passes validation, review and human approval.

Status: The board, sprints, sprint execution and reports are implemented and tested against the task state machine. Sprint analysis of imported Jira or GitHub tickets is implemented against simulated services and not verified live.

The board

Open Board and pick a project. The board is a view, not a separate status system. A card's column comes from two recorded sources: the task's status and the stage of its development workflow.

Column	Shows
Backlog	Draft and rejected tasks
Ready	Ready tasks
In progress	Queued, running and retry-pending tasks
Testing	Running tasks whose change is being validated, pushed or checked by CI
Review	Tasks awaiting independent review or human approval
Blocked	Blocked and failed tasks, and tasks needing reconciliation
Done	Approved and completed tasks
Cancelled	Cancelled tasks

Cards show the assigned agent, repository, dependencies, branch and pull request, test and CI status, blockers, estimated and actual credits, and the source issue when the task was imported.

Things the board deliberately does not do:

No progress percentages and no ETAs. Nothing is derived from stage order.
Actual credits are metered, never estimated. The field is empty when nothing was metered.
WIP limits are a flag, not an enforcement.

Moving cards

Dragging a card requests a real task transition. PWR finds the shortest legal path (at most two steps) into the target column, and every guard still applies: role minimums, agent checks, dependency checks and the audit trail. Developers and above can move cards.

You cannot drag a card into Testing, because that column is driven by the worker. A move with no legal path is refused with 409 illegal_move and the list of allowed targets.

Admins can change the column layout. Every task status must appear in exactly one column, so no configuration can lose tasks.

Sprints

Open Board → Sprints. A sprint has a name, a goal, a window, a credit budget and a maximum number of concurrent runs.

A project has at most one active sprint.
A task can be in only one open sprint at a time. A second booking is refused with 409 task_in_sprint.
Completing or cancelling a sprint freezes it and stores a snapshot of its report.
An active sprint cannot be deleted.

Executing a sprint

From an active sprint, choose Execute selected tasks.

Requirements:

the sprint is active;
the tasks are in the sprint and are draft or ready;
every selected task has acceptance criteria;
an agent is known: one you pick, or the single agent all selected tasks are assigned to;
a budget exists: one you enter in USD, or the sprint's remaining credit budget. PWR does not guess a budget.

PWR then creates a goal from the selected tasks, keeps their dependencies, moves draft tasks to ready, pins a per-task cost cap, and queues the first tasks that have no unmet dependencies. Parallelism is capped by the sprint's concurrent-run limit, and you can set the number of remediation attempts per task.

Every later step is the ordinary development workflow: validation, push and pull request, CI, independent review, human approval bound to the commit, and the merge gate. See GitHub integration.

Execution creates an autonomous goal, which must be included in your plan when billing is enabled.

Sprint analysis of imported tickets

If a project is linked to Jira or GitHub Issues, a Producer agent can analyse a sprint (a Jira sprint or a GitHub milestone) before anything runs.

The sprint's tickets are imported as draft tasks.
A read-only planning run receives the tickets as data and returns, per ticket: whether acceptance criteria are missing, whether it is eligible, needs_info or manual, its dependencies and blockers, a recommended role, a credit estimate range and a risk note.
The result is stored as a proposal. If the reply cannot be parsed, the analysis fails rather than guessing.
You approve a subset of tickets and a budget. Tickets without acceptance criteria or with an unresolved import conflict are refused.
The approved tasks become ready and run as a goal. All other imported tickets stay draft.
Results are written back to the tickets as recorded facts. See Jira integration.

An analysis moves through analyzing → proposed → approved → executing → completed, or failed. Find analyses under Integrations → Jira / GitHub Issues.

The eligibility assessment and estimates are a model's proposal for you to review. They are not a guarantee that a ticket will complete.

Sprint reports

Reports use recorded data only:

Tasks by status and by column.
Completed per day and burndown, taken from recorded task completions over the sprint window. Burndown is by task count, not by estimate. Nothing is interpolated or projected.
Credits consumed, summed from metered usage of the sprint's runs, and credits remaining against the budget. Empty when nothing was metered.
Blockers and pull requests from the sprint's tasks.

A planned sprint with no window has an empty burndown.

Limitations

Sprint budgets are in credits and goals are budgeted in USD. The conversion uses the active pricing policy's credit value.
There is no velocity forecasting or capacity planning.
Starting or approving autonomous work is always an explicit human action. Nothing starts from an import or a webhook.