Power: when authority captures the ceremony

The second failure mode of agile theatre: authority distortions that kill honesty. Velocity ratchet, estimate laundering and feedback banking — the three ways a power imbalance turns a ceremony against the team.

Every agile ceremony assumes a level playing field. Power is what happens when there isn’t one.

Planning poker only defeats anchoring if no one at the table can overrule the cards. A retrospective is only safe if honesty carries no cost. Velocity is only a forecast if no one above the team is grading it. Remove those assumptions — add a manager who signs off promotions, a metric that travels upward, an estimate that hardens into a promise — and the ceremony doesn’t just underperform. It inverts. It starts working against the people it was built for. This chapter names the three sharpest ways that happens, because naming them is the first step to refusing them.

The velocity ratchet

Start with the sharpest card of all: the person who invented story points has disowned them. “I like to say that I may have invented story points, and if I did, I’m sorry now,” wrote Ron Jeffries in 2019 — and specifically, “I think comparing teams on quality of estimates or velocity is harmful.” When the inventor of the unit tells you the unit is being used to hurt teams, the burden of proof shifts to anyone still using it as a scoreboard.

The velocity ratchet is how that harm arrives. Velocity is meant to be a team’s private self-calibration — the rolling average of points completed, used to forecast how long a backlog will take. The moment it leaves the room as a productivity target, it becomes a ratchet: last sprint’s number is this sprint’s floor, and the only direction it’s allowed to move is up. Teams aren’t stupid, so they respond the only way the incentive allows — they inflate. A story that was a 3 last quarter is a 5 this quarter, the number climbs, and nothing ships any faster. Even Mike Cohn, the pro-points authority, concedes the mechanism: the slightest hint that velocities will be compared produces gradual, consistent point inflation.

Velocity over six sprints with two outliers pulling the average above the sustainable rate 0 30 60 points avg 35 actual 29 s1 s2 s3 s4 s5 s6 easy sprint carry-over plan to the teal line, not the orange one
Velocity is a measure of pace, not productivity. The gap between the target line someone wants and the actual line the team can sustain is exactly the space point inflation fills.

The strongest citable basis for keeping velocity in its lane is DORA. A decade of research into what predicts software delivery performance produced four metrics — deployment frequency, lead time, change-failure rate, and time to restore — and velocity is deliberately not among them, because story points aren’t comparable across teams and measure effort, not delivered value. So the rule is simple and defensible: forecast with velocity, never grade on it. If someone outside the team is asking “is your velocity good?”, the fix is upstream of the number — the honest reply is “what are you actually trying to measure?” Our velocity chapter shows how to keep it honest, and velocity and capacity planning shows how to use it for the one thing it’s good for.

Estimate laundering

The second distortion is subtler because it looks like accountability. Estimate laundering is the quiet conversion of an estimate — a guess, made with the least information you’ll ever have — into a commitment, and then holding the team to it as if they’d signed a contract. The guess goes into the planning meeting; a deadline comes out; and when the deadline slips, it’s the developer’s fault for “missing their estimate.”

relabelled hardens it slips Estimate “Commitment” Deadline Blame a guess a promise a fixed date “you missed it” the guess is now treated as the team’s fault
The laundering runs as a loop: a guess is relabelled a commitment, hardens into a fixed date, and when it slips the miss is booked against the team — then it starts over.

Practitioners describe the whole laundering cycle without needing to be prompted: estimates magically become commitments, and if you don’t hit the number, it’s on you. Estimates get overruled — “that can’t be right, do it again” — until the team gives whatever figure makes the date fit, at which point planning is a charade with a predetermined answer. There’s even a revealing asymmetry in the language: say “this will take ten days” and a manager will press “are you sure it can’t be nine?”; say “this is ten points” and, for reasons no one can quite defend, the same instinct doesn’t fire. Story points were partly meant as armor against exactly that pressure — and estimate laundering is the pressure defeating the armor by converting the points straight back into a date.

The canonical corrective is Mike Cohn’s, and it predates our coinage: separate estimating from committing. An estimate is a probability distribution; a commitment is a decision the team makes about what it’s confident it can deliver. Keep them apart, out loud. Forecast a range and name the assumptions under it. And watch for the compounding case — when scope, time, and cost are all fixed upfront and the work is merely wrapped in two-week sprints, you don’t have agile with estimates, you have waterfall in a costume. Forrester’s Dave West named that “water-scrum-fall,” and estimate laundering is its beating heart. Our story points vs hours chapter unpacks why the conversion is the failure mode, not the fix.

Feedback banking

The third distortion is the darkest, because it turns the safest-sounding ceremony into a liability. Feedback banking is when honest retrospective input gets stored up and quietly withdrawn against you later — at a performance review, a bonus calibration, a quiet conversation about “fit.” The retro is sold as a safe space to be candid. Feedback banking is the discovery that candor has a settlement date.

The war stories are specific and they sting. One engineer described their retro feedback resurfacing in a yearly evaluation as evidence that they “complain too much.” Another put the mechanism plainly: management banks all the complaints for withdrawal at your annual bonus review. The chilling effect doesn’t even require malice — the person who signs off on promotions doesn’t have to say a word in the room. Their presence alone is enough to turn honest input vague, and to teach everyone that the smart move is to perform contentment. Our why retrospectives fail chapter covers designing the session so honesty stops carrying a career cost.

This is where the safety literature stops being hand-waving. Amy Edmondson’s work on psychological safety, and Google’s Project Aristotle — two years studying 180 teams — found psychological safety the strongest of the five factors it identified — the one the other four rest on. A team that has learned its feedback is being banked has no psychological safety, by definition, and the retro that pretends otherwise is theatre with a legal risk attached. The Scrum Guide frames the retrospective as the team inspecting itself — so why is the manager in the room taking notes?

Don’t rely on a hero

There’s a failure mode inside the fix. These distortions usually get held back because someone senior — a lead, an EM with spine — personally shields the team: refuses to hand velocity upward, reframes estimates as forecasts, keeps the retro’s contents in the room. It works, but only while that person stays. A shield is not a system. If the honesty of your ceremonies rests on one manager’s willingness to absorb pressure, you don’t have safe ceremonies — you have a temporarily benevolent one, and the theatre resumes the day they leave.

That’s the difference between Power as a failure mode and Power as a fixed thing. The psychological safety chapter covers building candor that doesn’t depend on who’s in the room, and the Prime Directive covers the norm that makes it stick. When the captured ceremony finally produces nothing but managed appearances, you’ve arrived at the follow-through void — the fourth mode, and the one where feedback banking does its quietest damage.

Frequently asked questions

How do I stop management using velocity against my team?

Keep the number in the room. Velocity is a forecasting input, not a performance metric — the DORA research deliberately excludes it because points aren’t comparable across teams. If a manager outside the team is asking whether your velocity is good, the honest answer is a question back: what are you actually trying to measure? Report outcomes and delivery, not point totals.

Can retrospective feedback be used against me in a performance review?

It happens, and the fear is rational — practitioners report honest retro input resurfacing months later as a note that they complain too much. That’s feedback banking, and it’s why anonymity, manager-exclusion and the Vegas rule exist. A retro where candor is a career risk isn’t psychologically safe, and no facilitation technique fixes it. Fix the power setup, not the wording.

How do I stop estimates from becoming deadlines?

Separate estimating from committing, out loud and on purpose. An estimate is a probability; a commitment is a promise; laundering one into the other and then holding the team to it is where the trust breaks. Forecast a range, name the assumptions, and never let a guess made in a planning meeting get quoted back as a date the team signed up for.

Should my manager attend the retrospective or run the stand-up?

Generally no. The Scrum Guide frames the retrospective as the team inspecting itself and the daily as the developers’ own coordination. An authority figure in the room doesn’t have to say a word to dampen honesty — the person who signs off promotions is a chilling presence by default. Share the action items upward, not the seats.