Overview

Decide, at the start, which two constraints are genuinely fixed and let the third become the dependent variable everyone tracks explicitly. If nobody makes this move, the trade-off still happens -- just silently, usually as a quality cut nobody notices until it is too late to reverse cheaply.

The shape of the work: waterfall fits a high cost of course-correction with stable, externally mandated requirements; Scrum fits a high rate of requirement change with an engaged customer who can reprioritize every sprint; Kanban fits continuous, unpredictable work arrival with no natural iteration boundary. The methodology should follow the work's shape, not fashion.

Independently estimable (a team member could size it without decomposing it further) and independently assignable (one name or one pair can own it end to end without splitting it across unrelated owners).

The single longest cumulative-duration chain from start to finish in the dependency graph. Every task on it has zero slack: delaying it by one day delays the whole project by one day.

Relative sizing embraces uncertainty instead of faking a precision no team actually has; humans are better at "bigger or smaller than this" than at absolute duration prediction. Velocity (points completed per sprint, averaged over several sprints) turns relative sizes into a forecast: divide remaining backlog points by average velocity.

Anchoring, neutralized by a blind simultaneous reveal (no spoken number can pull anyone else's guess). Authority bias, neutralized by having the highest and lowest estimators explain their reasoning first when estimates diverge, rather than deferring automatically to the most senior voice.

Committed points must never exceed the team's known velocity, and no task in the plan may precede a dependency that is not itself scheduled in an earlier sprint.

Blockers, not a chronological status recitation. A WIP limit caps how many items one workflow stage can hold at once, forcing attention onto finishing started work rather than starting more -- and both mechanisms exist to move the moment a problem is discovered as early as possible.

A one-sentence "when this metric shows X, we do Y" decision rule must be writable for it. A metric with no such rule is decoration and should be dropped.

A likelihood rating, an impact rating, a computed likelihood-times-impact score, a mitigation specific enough to act on (not "monitor closely"), and a named owner accountable for that mitigation.

What the triple constraint absorbs -- what is dropped, delayed, or funded -- to accommodate the change, run through an explicit accept/defer/trade decision rather than slipping in silently.

A named owner and a measurable done-signal -- something checkable next sprint, not a vague intention.

The specific decision that update is meant to drive -- reprioritize, fund a mitigation, adjust a date, approve a change -- not merely what information the update contains.

"When a measure becomes a target, it stops being a good measure." In delivery work: the instant a team's velocity is used to judge or rank its productivity, the team gains a direct incentive to inflate point estimates -- same actual work, a bigger declared number, and the number now lies to everyone who relies on it for forecasting.

n(n-1)/2, quadratic in team size. Because coordination cost scales with that quadratic curve while a fixed ceremony package's cost is roughly flat per person, the "right size" of process genuinely differs by team size -- a package barely-there on an eight-person team can dominate a two-person team's week.

This is the impossible ask co-01 warns against: fixing scope, schedule, and cost simultaneously is not a plan. The team's first move is not to attempt all three -- it is to force an explicit conversation about which two are genuinely fixed (the grant deadline almost certainly is; the already-spent budget likely is too) and get an honest answer about what the third -- scope -- must absorb, in writing, before any work begins.

Kanban. Work arrives continuously and unpredictably from telemetry, with no natural sprint-length iteration boundary to plan two weeks of it around -- exactly the property co-02 names as Kanban's fit, not Scrum's fixed-cadence reprioritization or waterfall's locked-plan approach.

It fails co-03's independently-estimable-and-assignable test: it spans three unrelated services with no single owner, so nobody can size it with confidence or take end-to-end ownership of it. It should be decomposed into three separate leaves, one per service, each assignable to a single owner.

Two paths reach D: A -> B -> D = 2+5+2 = 9 days, and A -> C -> D = 2+3+2 = 7 days. The critical path is A -> B -> D at 9 days, with zero slack; A -> C -> D carries 2 days of slack (C could run 2 days long before it affects D's start).

An hour estimate claims a confidence the team does not actually have at the start of a task -- it looks precise without being accurate. Story points sidestep this by asking only "bigger or smaller than this reference," a comparison humans are demonstrably better at than absolute duration prediction (co-05); the apparent precision of hours is the flaw, not a feature.

Authority bias -- the tech lead's number becomes the anchor everyone else defers to rather than one opinion among several. The fix is a blind, simultaneous reveal (co-06): every participant locks in a card privately before anyone's number is visible to anyone else.

Lines of code committed per day, Slack message count, and meeting-attendance rate all fail: none has a stated "when this shows X, we do Y" decision attached, and none of the three obviously maps to one either (more commits or more messages does not clearly call for any specific action). Burndown, cycle time, and lead time each pass, because each already has a concrete decision co-09's worked scenario mapped to it.

"Monitor closely" is not a concrete, actionable mitigation -- it describes an intention, not a committed action, and "team" is not a named individual accountable for it. A concrete rewrite: "Pin the API's SDK version, subscribe to the vendor's changelog, and smoke-test weekly against their sandbox environment," with a single named owner (co-10).

Route it through an explicit accept/defer/trade decision against the triple constraint, not silently squeeze it in. The response should state what X's addition would cost -- a schedule slip, a dropped lower-priority item, or added budget -- and let the stakeholder choose, rather than absorbing it invisibly.

Goodhart's Law (co-14): the moment points shipped affects compensation, teams gain a direct incentive to inflate estimates -- identical work, bigger declared numbers. This also destroys the number's original, legitimate use: the team's own historical velocity becomes meaningless for forecasting (co-05) once it has been inflated to chase the bonus.

The 15-person team has 15*14/2 = 105 communication paths -- far too many for ad hoc "talk when we need to" coordination to actually cover; without structured ceremony, work will silently drift out of sync across most of those 105 paths. The 3-person team has only 3*2/2 = 3 paths; the identical heavyweight package is wildly oversized for that little coordination surface and consumes a disproportionate share of a 3-person team's week for coordination need that does not exist (co-15). Both are process-weight mismatches, in opposite directions.

After:

Root cause: a risk with a mitigation but no named owner is not actually being managed -- nobody is accountable for doing the mitigation, so it competes with everyone's other priorities and loses by default. co-10 requires all four fields: likelihood, impact, score, mitigation, and a named owner.

After:

2.0 Platform Work
  2.1 Payments service: checkout endpoint change
  2.2 Notifications service: delivery API change
  2.3 Auth service: session-refresh change

Root cause: "Backend work" spans three unrelated services with no single owner or skill area -- it fails co-03's independently-estimable-and-assignable test. Splitting it by service produces three leaves a team member can size and own individually.

After: add the missing edge, Design review -> Implementation (implementation cannot meaningfully start before the design is reviewed and approved). The critical path recalculates to Design review -> Implementation = 3 + 6 = 9 days, three days longer than the flawed original.

Root cause: an omitted real "must finish before" relation implicitly claims two tasks can run in parallel when they cannot -- co-04 requires every genuine precedence relation to be encoded as an edge. Missing even one edge on the true critical path understates the schedule and sets the project up to commit to a date it cannot actually hit.

After: commit Task A (10) and Task B (8) -- 18 points, under the 20-point ceiling. Defer Task C (8 points) to the next sprint.

Root cause: co-07 requires committed points to never exceed known velocity. A 26-point commitment against a 20-point velocity sets the team up to either work unsustainable hours or ship a broken promise -- the fix is to cut the lowest-priority item, not to hope the team beats its own historical average.

After: walk the board right-to-left, closest-to-done first; ask exactly two questions per card -- "is this blocked?" and "has this been sitting longer than two days?" -- rather than asking each person to self-report.

Root cause: self-reporting depends on someone recognizing their own situation as "blocked," which the four-day-stuck card shows doesn't reliably happen. Asking a fixed diagnostic question per card, board-driven rather than person-driven, catches exactly what self-report missed (co-08).

After:

Root cause: an update with no attached decision is status theater regardless of audience -- co-13 requires every row to name what actually changes, for someone, as a result of that update.

After: use the three-sprint average, (14 + 16 + 22) / 3 = 17.3, rounded down to 17 for conservative planning: 66 / 17 = 3.9, rounded up to 4 sprints.

Root cause: cherry-picking the best of three sprints produces an overly optimistic forecast -- co-05 requires an average of at least three sprints specifically so one unusually good (or bad) sprint cannot dominate the number the team commits a stakeholder-facing date to.

co-05 and co-10 both replace an impossible demand -- predict the future precisely -- with an honest one: commit to the most defensible number available right now, given genuine uncertainty. Grading an estimate against actual hours after the fact treats it as if it were a prediction, which punishes honest uncertainty and teaches the team to pad future estimates defensively -- exactly the Goodhart-style distortion co-14 names for velocity used as a performance target. Pragmatism means the number stays useful for its actual purpose (relative sizing, forecasting) precisely because it was never asked to be "correct" in an after-the-fact sense.

There is no single correct trade-off computable from first principles -- the right trade depends on the specific stakes of a specific project (a fixed grant deadline versus a flexible internal tool), which is a judgment call, not a calculation. What co-01 actually teaches is not "compute the right answer" but "make the trade-off explicit and owned." Pragmatism here replaces an impossible search for one objectively correct answer with an honest, visible, chosen one -- the discipline is in the naming, not in the arithmetic.

Because agreement reached through anchoring or authority bias is not actually the team's honest judgment -- it is one person's judgment the rest are quietly deferring to. There is no objectively correct point value for a team to converge on, only a more or less honest one; the facilitation rules exist to make the eventual agreed number pragmatically closer to what the team collectively, honestly believes, which is the only kind of "correct" available here.

Coupling, in code, means one component cannot change independently of another. On a project schedule, a task with zero slack is coupled to the project's finish date in exactly that sense: you cannot delay it without delaying everything downstream of it. Framing the critical path as coupling, not merely "long," is what makes co-04's actionable insight visible -- expedite the coupled chain specifically, not just whichever piece of work looks biggest.

A leaf that is independently estimable and assignable is, by definition, cohesive -- it is one coherent unit of work, not several unrelated concerns bundled together. A leaf like "backend work" spanning three unrelated services is low-cohesion: it bundles unrelated concerns, which is exactly why it resists being sized or owned by one person (Drill 2). Decomposing it into cohesive leaves is the project-management equivalent of decomposing a low-cohesion module into focused ones.

Every communication path is a coupling between two team members -- a channel through which one person's work can silently drift out of sync with another's unless something actively holds it together. As team size grows, the number of these couplings grows quadratically, which is exactly why ceremony has to scale non-linearly too. This is a structural coupling argument about the team itself, distinct from co-08's separate concern (which mechanisms make in-flight work visible day to day) -- co-15 is about how much of that mechanism a team's actual coupling structure needs in the first place.