The Risk That Was Too Small to Raise

One week. That was the entire risk.

A requirement was going to take a week longer than planned. Everybody knew. Nobody did anything, for three sprints, because a week is not the kind of thing anyone calls a risk.

In the fourth sprint it blocked the stream.

Why It Was Never Raised Properly

On that programme, and on most programmes I have worked on, the word risk had drifted to mean one specific thing: something that could kill the project.

Vendor pulls out. Integration cannot be built. Budget disappears.

That definition has a side effect nobody intends. If a risk is a project-killer, a week's slip is not a risk — it is a fact about the schedule. No form, no owner, no forum where it fits, and raising it feels like escalating something trivial in front of people whose time is expensive.

So small problems do not enter the system at all. Not dismissed. Never entered.

And small problems are the ones that compound, for a reason that is structural rather than bad luck: they are not independent. A week here and a week there land on the same dependency chain, and the plan has enough slack to absorb the first one, some slack for the second, and none at all for the third. The fourth sprint does not fail because of a new problem. It fails because it is the first sprint that has run out of absorbency.

Small risk plus small risk plus small risk equals big risk. That is not a slogan about vigilance. It is arithmetic about slack.

The Second Failure Mode: Killing the Channel

Sometimes the risk does get raised. That is when the other failure appears.

A tester raised one for weeks. The answer that came back was: that is what you are here for.

The risk materialised. Of course it did — nothing about the response changed the world, it only changed who was carrying the worry.

But the expensive part is not that one event. It is what the answer taught. A tester who raises a risk five times and gets that response five times stops raising them, not out of sulking but out of a completely rational reading of the evidence: this costs me effort, it produces nothing, and it makes me the person who complains.

Ignoring a raised risk does not make the risk go away. It makes the reporting go away.

And the reporting was the asset. It was the earliest signal the programme had, produced for free by someone who happened to be looking at the right thing.

That answer also reveals the underlying assumption. That is what you are here for treats QA as a catcher of bad things — the net at the bottom, whose function is to absorb whatever falls. Not a party to the plan. Which means information from QA gets read as complaint rather than as data, no matter how it is phrased.

The Cost Lands Somewhere Else

The clearest case I have seen of that: a data model implementation planned at two weeks took five to six.

That is a development-stream event. Nobody in that stream experienced it as a catastrophe — it slipped, they worked through it, it landed.

What it did was eliminate automated testing from the project.

The automation window was defined by everything that had to happen before it and by a date that did not move. Three or four extra weeks upstream did not compress the automation work. It removed it.

Nobody decided that. There was no meeting where somebody weighed automation against the schedule and chose the schedule. The delay was not raised in time as something that would reach QA, so by the moment the impact was visible there was no decision left to make. The calendar had already made it.

That is the shape of the thing. A change in one stream changes every stream, and the stream that pays is rarely the stream that slipped.

Raising a Small Risk So It Survives

The reason small risks bounce is usually the way they are phrased. "This might be late" is a mood, and it is easy to answer with reassurance. Give it structure and it becomes something a project manager can act on.

• Name the dependency, not the delay. A week means nothing on its own. "A week that pushes this past the point where the next stream can start" is a sentence with a consequence in it.
• State the date it becomes irreversible. Every risk has a moment after which mitigation is no longer available. That date is the only urgent thing in the message, and it is almost always missing from how testers raise things.
• State what you would do differently if it lands, and when you need the decision. This is the move that changes the conversation. You are no longer reporting a worry — you are asking for a decision by a date, and unanswered decisions have a different social weight from unanswered concerns.
• Log the raise and the response, with names. Not for blame. So that when it materialises, the conversation is about what to do next rather than about whether anyone knew.
• Put development slippage on a standing weekly item. QA needs to hear about a dev slip the week it happens, not at the retro. By the retro the strategy consequences have already been decided by default, and a retro action item cannot give you back the automation window.

Why QA Sees It First

Testing sits downstream of everything. That position is uncomfortable most of the time, and it comes with one genuine advantage: QA is where two upstream slips first become one impossible schedule.

Development sees its own week. Design sees its own week. Only the stream that consumes both of them sees the sum — which means the earliest credible warning on most programmes is produced by a tester, and it arrives in the format the organisation has trained itself to discount.

Raise it small, raise it early, and raise it with a date. It is still the cheapest test you will run all sprint.

What is the smallest thing on your programme right now that you have decided is not worth mentioning?