Review and planning
Evaluate a proposed requirement, approve it or return it with a reason, refine it, set priorities, and plan, order and approve a release before any agent starts work.
- Availability: Experimental
- Evidence: Read from source
- How-to guide
Before you start
Every action on this page is a human decision and needs the permission Take decisions in the project. An agent can propose; it can never approve, order or launch. See the role table.
Approving something here starts nothing. Approval, launching an agent and the agent's work being finished are three separate records: see the work status vocabulary.
Evaluate a proposed requirement
A request in Human evaluation (in the list: Needs a decision) carries a Proposed requirement with three parts: Title, Expected change and Acceptance criteria. The decision is stated at the top of the request: "A definition is proposed. Approving it creates the requirement; returning it asks for another analysis with your reason."
- Read The request as it was written first, then the Proposed requirement. If the page warns "This definition read revision 1; the request is now at revision 2.", the proposal was written before the author edited the request: consider returning it.
- Decide:
| Decision | Control | What it does |
|---|---|---|
| Approve | Approve requirement | Creates the requirement, with a reference such as D-1, in the state Approved · not scheduled. The history records "A person approved this definition for development." |
| Return | Reason for returning, then Return to intake | Sends it back for another analysis. "The reason is what the next analysis works from, so it does not repeat itself." |
| Reject the ask itself | Dismiss this request, with a Reason for dismissing | Closes the request. It keeps its text and history and creates no requirement |
There is no button called "reject" for a proposal: a proposal you disagree with is returned with a reason, and a request that should not be done at all is dismissed.
Expected outcome of an approval: "Saved.", the request reads Approved, and the requirement appears under Requirements.
Keep one current definition
Requirements ("Keep one current definition.") shows each approved requirement with its state, "Definition 1" and its priority.
To change a definition after approval, open Refinement and history:
- Fill in Reason and edit Title, Expected change and Acceptance criteria.
- Choose Propose refinement. It is recorded as Proposed and changes nothing yet.
- A person chooses Apply proposal. The definition becomes "Definition 2" and the previous one stays readable as "Previous definition 1".
A refinement can be applied only while the requirement is Approved · not scheduled. Afterwards you may see "This requirement belongs to a planned release." or "The definition changed after this proposal was written. Propose the refinement again."
Set priority
On a requirement that is Approved · not scheduled, choose Priority: High priority, Normal priority or Low priority, then Save priority. Priority is information for the people who plan. It does not order agents and starts nothing.
Plan a release
Planned releases ("Organize delivery by release.") groups approved requirements into a unit of delivery.
- In Plan a release, fill in Release name and Objective.
- Under Select approved requirements, tick the ones to include. Only requirements that are approved and not yet scheduled are listed; with none, the form says "No approved, unscheduled requirements are available."
- Optionally, under Planned releases this one waits for, tick earlier releases: "Development cannot be launched until every result of a selected release is accepted."
- Choose Create planned release.
Expected outcome: the release appears as Proposed, numbered "Planned release 1", with its scope listed.
If you see "A selected definition changed. Create a planned release using its current revision.", a requirement was refined while you were planning: refresh and create the release again.
Order releases
Each release shows Deliver earlier and Deliver later. They move it one position in the delivery order. The order is what people work to; it does not launch anything.
Approve the scope
On a Proposed release, choose Approve scope.
Expected outcome: the release reads Approved scope, and the form Launch development appears. The scope is now frozen for that release.
Approving the scope does not start development. Launching is a separate, explicit action described in External work.
Human approval and agent work are different things
| A person does | An agent does |
|---|---|
| Answers questions, approves or returns a proposed requirement, dismisses a request | Reads the repository, asks questions, proposes a requirement |
| Refines, prioritizes, plans, orders, approves the scope, launches development | Claims launched work, reports progress, reports a blocker, submits a result |
| Accepts or returns a result, requests a test, accepts or rejects it, approves for production | Nothing on the delivery side |
The server enforces the left column for people only. If an agent's credential attempted any of it, the answer would be a refusal.
Limits
Next action
With the scope approved, launch development with an external agent.
Related: Requests · Work status vocabulary · Delegate recovery