Iterations

Iterations are horizontal delivery slices across approaches. They group work that should ship together into a coherent release.

​

What iterations are NOT

• Not sprints. No fixed timebox. An iteration is done when its work is done.
• Not releases. No deployment coupling. You might deploy continuously while working toward an iteration milestone.
• Not sequential. Multiple iterations can be active at once. Work on “Phase 2” can start before “Phase 1” is fully done.

​

What iterations ARE

Iterations are thematic groupings. Each one pulls jobs from multiple approaches across multiple goals. When you filter the Delivery Map to an iteration, you see exactly what’s in scope. A focused view of “what are we delivering right now?” The best iterations are cross-cutting. They group work by theme across branches of the tree, not by location in the tree. An iteration called “Model refinement” with jobs from three different goals is healthy. An iteration that’s just “everything under Goal 3” is probably too narrow.

​

Planning an iteration

​

Start with the rocks

When planning what goes into an iteration, start with the big-ticket items. The 2-3 approach-level deliverables that define the theme. Then add supporting work (medium jobs that unblock or validate the big bets). Then fill remaining capacity with small fixes and polish. If you start with the small stuff, you’ll never fit the strategic work. An iteration full of polish and small tasks will ship, but it won’t move the needle.

​

Watch for scope creep

If an iteration keeps growing, jobs being added, moved out, replaced, but isn’t shipping, it’s time to rescope. Ask: “What’s the minimum subset I could ship today?” Split the iteration. Ship the core. Defer the rest. The warning signs:

• Jobs keep getting added after initial planning
• The iteration has been active for multiple work sessions without completing
• Jobs get moved out to Later repeatedly

An iteration that keeps growing is a planning problem, not a delivery problem. Tighten the scope.

​

The Later iteration

Every project has a system iteration called Later. It’s the inbox, all unassigned work defaults here. Later is hidden from the Delivery Map unless explicitly selected. When you capture an idea but aren’t ready to commit it to a delivery slice, assign it to Later. During planning, you pull jobs from Later into real iterations.

​

Don’t let Later become a graveyard

Small tasks parked in Later indefinitely cost more to rediscover and re-evaluate than they would to just complete. If a task has been in Later for multiple iterations and would take less than 30 minutes. Pull it into the current iteration or delete it. The overhead of tracking it exceeds the work itself.

​

The key principle

A need does not need to be completely met before moving on. Ship the first version of an approach, the minimum that lets you test whether the bet is worth it, then move on to the next bet. Come back later with a more advanced version when the signal says it’s time. This is the core delivery principle: you’re not finishing one thing before starting another. You’re making balanced progress across multiple bets, shipping just enough proof at each step to know whether to go deeper. The advanced version of approach Y can wait while you get the initial version of approach X into the world. Each iteration is a balanced portfolio of work across multiple goals, not a serial march through one.

​

Iteration lifecycle

Marking an iteration done doesn’t affect its jobs. They retain their iteration assignment for historical reference.