Most sprint boards have a blocked indicator. Most teams stop paying attention to it within a few sprints. The reason is not that blockers stop happening. It is that the indicator gets applied to everything, loses meaning, and the team learns to ignore it. By the time a real blocker shows up, it looks identical to a dozen things that were marked blocked weeks ago and resolved themselves quietly.
This is not a discipline problem. It is a definition problem. Most tools give you one way to express a dependency, and teams end up using it for two fundamentally different situations that require different responses.
The two situations that get lumped together
The first situation is an active impediment. A story cannot move forward right now because something specific is in the way. An API endpoint is broken and the backend team has not fixed it. A design file was not delivered and the story cannot be started without it. A third-party service is returning errors. Progress has stopped. Someone needs to act today.
The second situation is a planned sequencing constraint. A story logically follows another in the order of work, but the prerequisite is on track and there is no active crisis. A billing report cannot be built until the payment integration is done. A user profile page needs the authentication system to exist first. These relationships matter for planning, but they do not need escalation in today's standup.
One is a fire alarm. The other is a calendar note. When both use the same indicator on the board, the fire alarm stops working.
What dependency fatigue looks like in practice
The pattern is consistent. Early in the team's life they mark things blocked carefully. Over time the marker gets applied loosely, sometimes to things that are waiting, sometimes to things that are sequenced, sometimes to things someone just wanted to flag. The board fills up with blocked indicators. Standups start ignoring them because half the time the block has already resolved. Eventually the team stops using the marker at all, and real blockers surface only when someone mentions it verbally.
This is dependency fatigue. The signal collapsed into noise because there was no distinction between urgent and planned. Tools that give you one dependency type create this problem by default.
How to separate the two
The practical fix is to treat blocked and depends on as two different concepts with different visibility and different responses.
Blocked means someone needs to act now. It belongs in the standup. If a story has been blocked for more than two days without resolution, it should be escalated or pulled from the sprint. It is an operational signal, not a planning note.
Depends on is a planning constraint. It belongs in the backlog and the sprint planning conversation. Use it to make sure you are not pulling a story into a sprint before its prerequisite is done. Review it when planning multiple sprints ahead. It is not something that needs standup attention unless the prerequisite is slipping.
A fast test: can the person assigned to this story work on it today if they wanted to? If yes, it is a sequencing constraint. If no, and the reason is a specific other story or issue, it is a blocker. The test takes three seconds.
Why this matters for sprint planning
When you cannot quickly distinguish stories that are currently stuck from stories that are just sequenced after something else, sprint planning goes wrong in a specific way. You either overreact to non-issues and spend planning time on things that are fine, or you underreact to actual blockers because they look the same as everything else. Neither is a good default for a team trying to close a sprint reliably.
The depends on relationship also serves a second purpose in planning: it tells you which stories cannot enter a sprint until something else is done. If you are pulling work into a sprint and story B depends on story A, and story A is not yet complete, story B is not ready. Surfacing this during planning is significantly less painful than discovering it mid-sprint when someone picks up story B and immediately hits a wall.
The blocked checkbox versus the blocked by dependency
There is a third concept worth separating: external blockers. A story can be stuck because of something that has nothing to do with another story in the project. A vendor has not responded. A design decision has not been made. A stakeholder meeting has not happened yet. This kind of block has no source story to link to, but it still needs to be visible on the board.
The cleanest approach is to keep three separate concepts: a blocked flag for external impediments with a free-text reason, a blocked by relationship for story-to-story blockers, and a depends on relationship for planned sequencing. Each serves a different purpose at a different point in the sprint cycle. Mixing them together is how one indicator ends up meaning nothing.