A performance goal with no budget will not be executed

What it is

“Watch performance” and “don’t be slow” do not enter a sprint, because they cannot fail on a given change. What gets executed is a cap: over it, you cut scope, refuse the merge, or record an explicit overage. A goal with no cap always loses the queue to work that has a date and a range, and is therefore not a goal.

This is about whether the goal has force in the queue, not which device the cap is bound to, and not which pipeline runs the check. A performance wish with no number loses first when it competes for hands.

Why it happens

Sprints allocate constraints that can fail. Features have scope and a date, defects have a repro, budgets have over / under. A slogan has no failure state: whether or not anyone did anything this week, tomorrow can still say “we should watch it.” Performance work becomes optional polish, done when someone is idle, and idle almost never arrives.

A decidable cap turns the talk from “should we care” into “which line did this change cross, and what do we cut to get back.” Cutting a feature, swapping an implementation, splitting a bundle — those are execution. With no cap those moves have no legitimate reason, and a retro cannot point to the change that should have been stopped. Goals are not done because they were written as principles; they have to be able to veto a ticket or a release.

Where it stops holding

Early exploration that cannot yet measure can have “stand up a cap” as the goal, rather than pretending to be fast already — that is still decidable (was a budget written). When leadership has accepted present slowness and paused governance in writing, execution is politically stopped, not because the slogan was poorly phrased; writing the present as a cap is still useful because later regressions become visible. Research prototypes that never reach users can have no performance goal. A cap that is unreachable on the current architecture will not be executed either; it becomes ignored wallpaper and needs a reachable next step, not more slogans.

Applying it

• Rewrite every performance wish as a decidable cap. If it cannot be rewritten, take it off the goal list; do not leave it in a principles doc as filler.
• Give an over-budget change an action in the plan (cut, split, or an explicit overage). A cap with no action still will not be executed.
• In retros, count only goals that could have failed. “Watch it,” which never had a failure state, is not the quarter’s performance work.
• How to check: open last quarter’s tickets and principles that say “performance,” and ask of each “which change could have failed because of it.” If you cannot point to a failure point, the goal was not executed. Then look at what actually merged: was anything blocked or cut for crossing a cap? Never once, and execution still has not happened.

Related

• Same group: R3.04.1 A budget must be bound to a specific device and network · R3.04.3 A budget must be checked in the build pipeline
• Nearby: I2.07 Perceived performance · R3.15 First-paint metrics and interaction readiness
• Search terms: unbudgeted performance goal · performance slogan · decidable cap