What is the actual test for whether something is a real blocker?

Ask one question: can the work proceed right now, in any form, without the disputed decision being made first? If the answer is yes, even if the available path is slower or not the one the person prefers, it is not a blocker. If the answer is no, work has genuinely stopped, and that is what the word should be reserved for.

What is the difference between a blocker and a preference?

A blocker stops work outright: no version of the task can move forward until something specific changes, like a missing credential, a broken dependency, or a decision that only one other person can make. A preference is a disagreement about which of two working paths to take. The work is not stuck, someone just wants a different route than the one currently open.

Why does it matter if people mislabel preferences as blockers?

Because a standup runs on everyone trusting that "blocked" means "stop and help now." If half the reported blockers turn out to be a person wanting a different approach, the team learns to discount the word, and a genuine stoppage gets the same shrug as a stylistic disagreement. The cost lands on the one time the word was true and nobody reacted with urgency.

Is calling something a blocker when it is actually a preference dishonest?

Usually not on purpose. Most people are not trying to mislead anyone; they are using the word that feels closest to how frustrating the situation is, not the word that describes what is actually happening to the work. The fix is a shared definition the team applies consistently, not an accusation aimed at whoever said it.

Should a manager challenge someone who calls something blocked in a standup?

Yes, with one question, not a lecture: "if we did it your way right now, could you keep going?" If the honest answer is yes, the item gets relabeled to a preference or a decision needed, and the standup moves on. This should feel like a two-second clarification, not a cross-examination, or people will stop raising issues at all.

Where should a real blocker go if it cannot be solved in the standup itself?

To whoever can actually remove it, immediately, outside the meeting. A blocker that sits in the standup notes until tomorrow's standup has not been treated as a blocker at all; it has been logged as one and then ignored, which is worse than not raising it, because it creates a false sense that someone is already handling it.

What should happen to a preference once it is correctly labeled?

It becomes a decision to make, not an emergency to clear. Someone with the authority to choose picks a direction, on a timeline that fits how much the choice actually matters, and the person who raised it keeps working in the meantime rather than waiting on the outcome.

Does the Scrum Guide define what counts as a blocker?

The official Scrum Guide talks about identifying "impediments" in the Daily Scrum rather than defining a strict blocker versus preference split, but the underlying idea is the same: the event exists to surface things getting in the team's way so they can be removed, which only works if the team is consistent about what actually counts as one.

Does this apply outside of software teams?

Yes. Any team that reports status out loud, whether it is called a standup, a scrum, or a weekly sync, runs into the same drift once "blocked" becomes the word people reach for whenever they are annoyed rather than when they are actually stuck. The fix is the same test regardless of the discipline: can the work move at all, right now, without this being resolved first.

How is this different from just telling people not to complain in standup?

It is not about suppressing disagreement; a preference is worth raising, and the team should hear it. The fix is sorting it into the right bucket once it is raised: a preference needs a decision-maker and a timeline, a blocker needs someone to drop what they are doing and remove it now. Conflating the two means both get the wrong response.

How to tell a real blocker from a preference: Reveneau

We have sat in standups where four people said "blocked" in the same fifteen minutes, and only one of them actually was. The other three could keep working. They just did not want to work the way that was currently open to them: the API contract was not final, the design had two options and no decision, the library they wanted was not approved yet. Real friction, worth raising. Not a stoppage.

That gap matters more than it sounds like it should, because "blocked" is supposed to be the word that makes a team move fast. It is the signal that says: drop what you are doing, this person cannot proceed, go help. When a third of the things called blocked turn out to be things somebody would rather not do, the word stops carrying that signal. Here is the test we use to keep it honest, and why the mix-up costs more than a few wasted minutes in a meeting.

The test is one question, not a judgment call

A blocker is not a feeling. It is a fact about whether work can happen.

Ask this: can the task proceed right now, in some form, without the disputed thing being settled first? If yes, on the slower path, the ugly path, the path that will need rework later, it is not blocked. If no version of the task can move until something specific changes, it is blocked.

This test does not require anyone to argue about how frustrating the situation is. It just asks whether output is possible today. A missing production credential is a blocker: there is no way to deploy without it, full stop. A design with two unresolved options is not: you can build against one of them and adjust later if the team picks the other. The frustration might be identical. The state of the work is not.

The test also has to survive being asked out loud, in the room, without turning into an interrogation. The tone matters as much as the question. "If we went with your first choice right now, could you keep moving?" lands as a clarifying check. "Are you actually blocked, though?" lands as a challenge, and people stop volunteering problems once raising one feels like being cross-examined. Ask it the same plain way every time, aimed at the situation and not at the person, and it becomes routine instead of a confrontation.

What a real blocker looks like, and what it does not

A real blocker has a specific, nameable cause and a specific, nameable person or system that removes it. "I cannot deploy because the production credential has not been issued" names the gap and names who can close it. "I cannot merge because the CI pipeline is down" names a system, and everyone downstream of that system is blocked in exactly the same way at exactly the same time.

That last detail is a useful check on its own. A true blocker usually blocks more than one person, because it is a fact about the world, like a broken dependency or a missing permission, not a fact about one person's judgment. If you are the only one affected by a "blocker," ask whether it is a choice you are waiting on someone else to make for you rather than a stoppage that would catch anyone in your position.

A preference, by contrast, usually has an owner who could resolve it on their own if they chose to, just not the person who raised it. "I don't want to build the form this way until we agree on validation rules" is a real concern, but the person raising it could start on the parts that do not depend on the validation rules, or build against the current best guess and adjust later. Nothing about the world is stopping them. A decision has not been made yet, and they would rather not guess at it.

A preference disguised as a blocker still gets treated like an emergency

Once something is labeled blocked, it usually gets emergency treatment: someone gets pulled off their own work to unstick it, or the standup burns extra minutes debating it live. That response is correct for an actual blocker and wasteful for a preference wearing its name.

The Scrum Guide frames the daily meeting around surfacing "impediments," things getting in the team's way that need removing, precisely so the team can act on them fast. That only works if the team applies the label consistently. Practitioners writing about the distinction between a blocker and an impediment make the same point from the other side: a blocker halts work outright, while an impediment slows it without stopping it, and treating every impediment as a full stop burns urgency on things that did not need it.

The cost is not evenly spread. Most days, calling a preference a blocker just means a short, unnecessary discussion. The real cost lands on the day a genuine blocker gets raised and the room responds with the same mild shrug it gave the last five false alarms, because nobody can tell from the word alone which kind of problem they are looking at anymore.

Sort by consequence before you say the word

The fastest way to build the habit is to ask the second question before the first word leaves your mouth: what happens if this does not get resolved today?

If the answer is "nothing happens, I keep working on the version that is open to me," it is a preference. Write it down as a decision that needs to be made, name who makes it, and move on. If the answer is "I cannot do anything else on this task until it changes," it is a blocker, and it should get exactly the urgency that implies: someone drops what they are doing and removes it, now, not at the next standup.

This is also the fastest way to catch a blocker that is actually a decision problem masquerading as a technical one. "I'm blocked because I don't know which auth provider to use" often means "I could start against either one, but I want someone to pick so I am not the one who chose wrong." That is worth naming honestly. It needs a decision-maker and a deadline, not a war room.

Give the preference an owner and a deadline the same way you would give one to a blocker. A decision that sits open for two weeks because nobody was named to make it will eventually turn into a real blocker on its own, once every path that did not depend on it has been built out and the only work left needs the answer. A decision without an owner and a date is a note, not a plan, and it drifts until something forces it to matter.

What this costs a team that never fixes it

A team that lets the two blur together pays for it twice. First, in wasted urgency: engineers get pulled away from their own work to solve problems that were never actually stopping anyone, and that interruption has a real cost even when the fix takes five minutes, because switching tasks is not free for the person doing the switching. Second, and worse, in eroded trust: once a few false alarms have gone by, people start quietly discounting the word, and a standup where "blocked" no longer means "act now" is a standup that has lost its main reason to exist.

The fix is not more process. It is one shared definition, applied the same way by everyone in the room, checked with the same short question every time it comes up. That consistency is what makes the word worth listening to again.

The label is a promise, and a broken promise stops working

A word only works as a signal if it means the same thing every time it is used. "Blocked" is supposed to mean: stop, this cannot wait, come help now. The moment it also means "I'd rather do this differently," everyone hearing it has to guess which one it is, and guessing takes time the word was supposed to save.

When we scope a build with a client team, we set this distinction early, before the first standup, rather than correcting it after trust in the word has already worn down. It is a two-second question, asked the same way every time: can this proceed right now, some way, without the disputed thing being settled? That single check keeps "blocked" reserved for the moment it is actually true, which is the only moment the word is useful at all.

A blocker stops the work. A preference just wants a different one. Keep the difference, and the word "blocked" still means something the day it matters.

Sources

The 2020 Scrum Guide, Ken Schwaber and Jeff Sutherland: defines the Daily Scrum's purpose as surfacing impediments so the team can act on them quickly.
Solutioneers, "What is a Blocker? Agile Blockers & Impediments Explained": draws the practitioner distinction that a blocker halts work outright while a broader impediment slows it without stopping it.