Managing Project Outcomes

A team is 6 weeks into a project. The product owner asks the familiar question: "Are we on track?" Before agents wrote most of the code, there were three answers: "Yes"; "No, and here's what we need to cut"; and "No, and here's how much more we need to spend."

When implementation was the cost center, scope and spend were the only two levers.

Agents add a third. Once writing code is the cheapest phase of the work, the variable that decides whether you're on track is how much certainty you buy before implementation. This section is about managing that investment.

That the cheapest phase moved is easy to see. An agent can build a working version of an idea to react to faster than the team can wireframe one. A single spec can cover what used to take several developer-sized stories. What's less obvious is that the other costs of building software did not vanish. Planning, validation, architectural shaping, and keeping the team's mental model current with what shipped all still cost real time. Some of that time now has to be engineered back in deliberately.

Because of this, specs carry more of that weight than they used to. They have to spell out details an experienced developer would once have organically gleaned during implementation, like the micro-decisions made at the keyboard or the follow-up questions asked across the room. And the work that needs the tightest specs tends to also need the most architectural shaping and the hardest validation, since being wrong is more expensive there.

Two questions follow, which the rest of this chapter is oriented around. First, for each piece of work, how much certainty should the team build in before implementation? Those choices are Definition Strategies. Second, how does the team manage scope across the Product Backlog now that definition cost is larger and implementation smaller? That's the scope work: budgeting definition cost against a moving velocity is how the team decides what it can actually deliver. The two answers together also give the team somewhere to turn when projection diverges from plan. Beyond cutting scope or spending more, they can adjust the definition investment on whatever work remains.

Making the right trade-offs

Every piece of work in the Product Backlog asks the team to make a trade-off: they can either buy more certainty before implementation, or they can move faster and learn from the result. There are five ways to make that call, five Definition Strategies, running from heavy upfront specification to short build-and-react loops.

Three dimensions help teams decide which fits a given piece of work best:

The dimensions don't always line up on a single piece of work. Let the most constraining one drive the call: narrow acceptable-outcome targets with hard-to-reverse stakes pull toward the heavy end of the spectrum, while wide targets with easy reversibility push toward shipping and learning.

The information you do have also varies in its trustworthiness. Decisions from the product owner, user research, and production data are firm enough to spec against directly. Design explorations, technical spikes, and the team's own judgment calls move work forward but are bets, and the weaker the signal, the more a build-and-validate loop beats heavy specification.

Definition Strategy chooser

Show-and-React sits outside the normal matrix. It is the fallback when decision flow is blocked badly enough that the usual factors stop being predictive; ordinary low-information work still belongs in Guided Increment or Ship and Refine.

The default strategy is Guided Increment when risk allows. Teams should challenge high-precision specification by habit: extra upfront definition has to earn its cost, because a short, structured build-and-react loop often produces better signal faster. High-Precision Spec stays correct when the outcome space is narrow, hard to reverse, or expensive to misunderstand; it's just no longer the thing you reach for first. Do just enough definition to build something safe to learn from, put it in front of the product owner or users, and revise from the reaction.

The strategy is chosen per Backlog Item, one coarse product area inside the Product Backlog, when definition work on that item begins. Often the choice is already implied by earlier stakeholder alignment or the business context the team brings in. And different items in the same iteration One pass through the Planning → definition and implementation → Review loop, running twice per week. can run different strategies: one in a Guided Increment build, another being High-Precision spec'd for the next iteration, a third in Ship and Refine.

What this looks like by project context

The team chooses a strategy for each piece of work based on that work, not on the kind of project it belongs to. Project context still matters: different contexts pull definition work toward different strategies, and concentrate it in different places. The table below illustrates that pull across a few common contexts, showing how the same per-item choice adapts as the project changes.

Definition work exists on every project; it just looks different. If a team does not see itself in the process, the next move is to translate the model to its project context, constraints, and decision paths, rather than treating definition as optional just because the project context is different.

Managing scope

Scope management starts at the Product Backlog level, not the task level. The team sizes Backlog Items with the product owner using points on the Fibonacci scale. Agile readers can think of these items as roughly epic-sized; the important point is that they describe product areas large enough for prioritization and release planning. The total budget tells the team and product owner whether they will finish on time; the relative sizes show where the project's real cost sits.

Each item typically starts as a single large estimate: a block of time the team expects to invest in that area. As definition work surfaces detail, the item usually breaks into smaller pieces the team can sequence across iterations and interleave with other priorities. Each delivered piece burns part of the item's budget, giving velocity signal well before the whole item closes.

That gives each Backlog Item a micro-budget. When one is pulled into an iteration, the points drawn cover the combined cost of definition and implementation work for that iteration's delivery. A 20-point item might burn 6 points of definition work before implementation even starts: the info gathering, synthesis, and spec authoring required to get it ready. That visibility is deliberate. Definition cost shapes what the team can deliver, and the budget has to reflect it.

Velocity is how much the team is actually shipping, measured weekly or bi-weekly. Iteration-to-iteration throughput is too noisy for projection; patterns emerge over a few weeks. Compared to the estimates required to hit the timeline, observed velocity tells the team whether the budgets will hold. The gap between the two is the signal that drives replanning.

When velocity is running behind, the team can adjust more than scope and spend. A Definition Strategy sizes a piece of work across Definition and Implementation: a higher strategy buys heavier specification up front and usually pulls closer attention through the build too, more architectural shaping and tighter validation. So flexing the strategy down on remaining Backlog Items lightens definition and implementation together, which is what makes it a real lever rather than a paperwork change. That third move is strategy flexibility.

That improvement is not free. Velocity builds because the team spends part of its capacity on Compounding Work Work that improves the delivery system itself: stronger specs, better examples, agent instructions, review agents, patterns, tooling, and validation paths that future delegations can build on. : the investment that makes every later delegation faster and safer. Because it competes with features for the same budget, and features always feel more urgent, the team has to reserve capacity for it deliberately. A backlog that is all feature work moves fast for a few iterations, then slows as the system gets harder to reason about.

Example: Managing scope

Scope rarely holds still for a whole project. Here's the Backlog Item Seats & Membership absorbing a mid-stream change, with the team reaching for the third lever rather than only scope or spend.

Addressing project failure modes

When projection slips, the cause is often upstream of the estimate: Planning is underfed, specs are stale, decision flow is weak, or the team is using the wrong Definition Strategy for the remaining work. Use the signals below before changing scope, spend, or strategy selection. The first signal is usually the most visible, but its root cause is often one of the later ones.