Phase 2: Planning

How a team hands ready Definition work to Implementation and turns it into an iteration plan.

The Planning Phase is where work completed during a previous Definition Phase becomes assigned work to be completed during the next Implementation Phase. The Definition Phase’s output is synthesized context, Knowledge Base updates, and specs . But producing that output doesn't guarantee the team is ready for Implementation yet. A spec can seem finished and still hide a contradiction, a missing decision, or a dependency nobody scoped. Planning is where the team pressure-tests the specs together, settles what's still open, and commits only the work it actually understands well enough to delegate to agents.

Planning’s main new artifact is the effort : an agent-ready execution brief for a piece of assigned work, linked to its specs and kept current as a running log of the plan, checkpoints, decisions, deviations, and follow-ups. A good effort is what lets a developer hand substantial work to an agent while maintaining a record the team can review. A vague one gets paid for later, in review and rework.

What happens in this phase

Planning step	Activity	Tasks	Who executes
1	Review specs	Review the specs handed off from Definition work. Pressure-test them together to surface missing context, ambiguity, blockers, and architectural fit.	Team
2	Scope & assign	Lock in assignments and ownership. Set one clear priority path per developer, with smaller tasks assigned around it.	Team
3	Analyze & plan	Create efforts and Implementation plans for key work. Use agents to explore options and stage the work into checkpoints.	SoloCollab
4	Surface team concerns	Identify where plans affect other work: dependencies, shared patterns, validation needs, release sequencing, approval needs, and costly-to-unwind decisions.	Team

Running the ritual

Review specs

The first step is to review the in-scope specs as a team, so everyone understands the work being tackled and to ensure the specs are ready to build before committing to the work.

Participants

Full team

Goal

Align on what the work means and agree what is ready to build.

Steps

Review to ensure the specs handed off from Definition work together.
Surface missing context, ambiguity, blockers, and architectural fit.
Agree what is ready to build. Route substantial gaps back to Definition instead of turning planning into live spec-writing.
Check the structural work the queued specs imply. Most of it should already be settled by Definition’s architecture-focused specs, so planning verifies that direction rather than designing new structure. Build what can be decided and executed inside the iteration, and break out anything too big to resolve or too cross-cutting to fit a single feature's delivery, routing it back to Definition.

Key questions

Is this spec clear enough to build from?
Are there unresolved questions that would stall Implementation?
Can the structural decisions here be made and executed this iteration, or do they need to break out as their own additional Definition work?

Output

A set of specs the team agrees are ready to build, with gaps routed back to Definition.

Scope & assign

The team locks in who's doing what for the iteration. Smaller tasks keep the developer productive while longer agent runs are in flight.

Participants

Full team

Goal

Each developer leaves with one clear priority path and supporting work around it.

Steps

Lock in scope and assignments for the iteration.
Mix complex work with smaller, clear tasks for each developer.
Schedule the Compounding Work the team has prioritized: stronger specs, better examples, agent instructions, seeded patterns, validation automations. Feature work crowds it out otherwise.
Right-size tasks to fit the iteration. Work taken on at the start should be completable by the end, with mergeable progress along the way.
If a developer has two priority paths, both should be bounded enough to manage deliberately.

Key questions

Can each developer articulate what would merge right now? If not, the task is probably too large.
Is there Compounding Work in the mix, or is the iteration all feature work?
Can everything taken on be completed by the end of the iteration?

Output

Clear assignments with one priority path per developer, smaller tasks around it, and Compounding Work explicitly scheduled.

Analyze & plan

Analysis is the main opportunity for human judgment before implementation begins. The developer decides the approach, risks, and strategy before delegating substantial work to agents. Those decisions become the agent's working constraints. When they are vague, the team pays for the ambiguity in review and rework. Without a written plan, the team ends up reconstructing the work from chat history.

Participants

Solo or collaborative, depending on complexity

Goal

Each developer has a written plan that gives agents usable constraints and gives the team a review record.

Steps

For each piece of assigned work that needs planning, create or update one effort: the working document for scope, the Implementation plan, execution notes, deviations, and closure evidence.
If the approach is unclear, use the agent to inspect relevant code, propose alternatives, and narrow to a direction. If it's already forming, start with a rough plan and pressure-test it with the agent.
Write the Implementation plan: the proposed approach and how the work breaks down, especially for complex, risky, or high-stakes work.
Walk through the plan and look for where it could break: structure, architecture, non-functional requirements , validation, approvals, release strategy.
For complex, risky, or high-stakes work, pull in a pair before team review to challenge the plan. Break the work into stages with human review points, and review key design elements before broader Implementation begins.

Key questions

Are the agent's constraints specific enough, or will the team pay for ambiguity in review?
Where could this plan break?
Does this work need a pair before team review?

Output

A written effort with an Implementation plan that agents can execute against and the team can review.

Surface team concerns

Before Implementation begins, the team checks where plans affect one another. Not every plan needs full group review. Focus attention on the ones where one developer's work changes another's path.

Participants

Full team

Goal

Find cross-work impacts and agree on what must be coordinated before execution begins.

Steps

Walk through key plans and surface dependencies, shared patterns, architecture or infrastructure choices, approval needs, validation needs, and release sequencing.
Identify where one developer's plan changes another's path.
Agree on what must be coordinated before execution and assign follow-ups.

Key questions

Does any plan depend on or conflict with another?
Are there shared patterns or architecture choices that need agreement?
Who owns each coordination follow-up?

Output

Alignment on what must be coordinated before execution begins, with clear owners for each follow-up.

Example: Planning the Invite Members and Email Delivery efforts

Definition hands Planning two ready specs from the Backlog Item Seats & Membership: the feature spec Invite Members, and the technical spec Email Delivery that the tech lead wrote ahead of the iteration. Here's how one session turns them into assigned, agent-ready efforts.

Running example · Invite Members and Email Delivery efforts

Review specs (whole team). Reading the two specs side by side, the team hits a contradiction. The Invite Members feature spec assumes the email goes out the instant the admin sends it, with the screen confirming right away; the Email Delivery technical spec puts delivery a moment later, in the background. They settle it in the room: the invite table's Pending row will show the invite moving through sending, then sent or failed, with a resend. Everything else in both specs is answerable on the page, so nothing routes back to Definition and both are cleared to build.

Scope & assign (whole team). The Invite Members effort fits in one iteration, so it goes to one developer as their priority path; the Email Delivery effort goes to another. The admin "Sent emails" view is small enough to ride along with Email Delivery as Compounding Work instead of its own assignment. Both developers also pick up a lighter task or two to stay productive while long agent runs are in flight.

Analyze & plan (each developer, with an agent). Each developer opens an effort and drafts the plan with an agent. The Invite Members effort lays the build out as checkpoints to review before moving on: schema, seat reservation, modal, permissions, then the invite table's Pending row. It also names the one risk worth deciding up front: two admins accepting into the last open seat at the same moment, handled by checking and claiming the seat in one step, so only one of the two can win. The Email Delivery effort covers three things: the sender interface, background sending, and a pretend sender that records messages instead of actually sending them. Planning that pretend sender raises a testing question: how does anyone confirm an email really went out? The answer becomes the staging "Sent emails" view: every message is kept and displayed on an admin screen, so anyone can verify an invite was sent.

Surface team concerns (whole team). Back together, the team looks for places the two efforts collide. There's one: Invite Members calls the email module, so both developers can't define that interface on their own. They agree on its exact shape on the spot, and both efforts build to it. That settles the order of work too; the module can grow behind the interface while Invite Members builds against it and demos on the pretend sender, so neither developer is blocked on the other.

Output. Two agent-ready efforts, an agreed module interface, the sending-to-sent behavior for the invite table's Pending row pinned down, and a staging "Sent emails" view scheduled. Invite Members and Email Delivery can be built at the same time.