A deadline is negotiated on scope, never on quality

The request always arrives the same way. The product is 80 % ready, the date has already been announced to the client, and someone asks whether we can "tighten things up a little".

The honest answer is yes. You can always tighten. The real question is: on what.

There are only three variables

A project rests on three axes: scope, time and quality. Fixing all three is impossible — that is arithmetic, not an engineering stance.

When the date is imposed, two levers remain. Scope is visible: everyone understands that a feature moves to the next release. Quality is invisible: nobody sees that the tests were skipped, until the day everybody sees it.

That is exactly why quality is the default lever. It does not defend itself.

What "cutting quality" actually means

Nothing abstract. Here is what goes first, in order:

1. Edge-case tests — the ones that only fire in production.
2. Error handling — a generic 500 instead of a useful message.
3. Code review — "we'll look at it after the release".
4. The decision record — six months later, nobody knows why it was built this way.

The first three cost incidents. The fourth costs the team: a developer who does not understand the code they maintain eventually rewrites it, or leaves.

The phrasing that works

I never say "that's impossible". I say:

"For that date, here is what ships: A, B and C. D and E move to the next release. If D is essential, then B comes out."

That sentence turns a refusal into a decision. It makes the cost visible and leaves the choice to the right person — the one carrying the commercial responsibility.

And above all, it is verifiable. If I was told yes, it is written down. If I was told no, that is written down too.

What we write down

Every deferral fits in three lines in the backlog:

Deferred : PDF accounting export
Reason   : v1 scope held for the 12/09 date
Cost     : clients export to CSV in the meantime
Review   : sprint 24

Without that trace, a deferral becomes an oversight. And an oversight, six months later, is called technical debt — when it was in fact a deliberate decision.

The time I was wrong

On a business data migration, I agreed to shorten the verification phase. The argument seemed sound: the data came from a system we knew, and the format had been stable for years.

It was. Except for 0.4 % of the records, entered by hand between 2014 and 2016, with a decimal comma instead of a point.

The migration worked. The amounts were wrong. We found out three weeks later, at monthly close.

Since then, verification is no longer a phase — it is an exit criterion. It cannot be cut, because it is no longer a separate step you can remove from the plan.

That is the only genuinely reliable way to protect quality: do not let it be a line in the schedule.