Making dependencies visible: why projects die of waiting
A project rarely stalls because someone is working too slowly. It stalls because someone is waiting.
And waiting is treacherous: it shows up in no report. The board shows five tickets "in progress", the summary shows movement — but three of those five are sitting still, waiting for something that is written down nowhere.
Dependencies live in people's heads
Ask any team which ticket blocks which. You will get an answer, and it is usually correct. It just isn't recorded anywhere.
That works as long as the same three people talk every day. It breaks the moment someone falls ill, someone new joins, or the project grows bigger than a conversation.
The damage shows up late:
- Someone starts a ticket that cannot start yet and works half into the void
- A predecessor gets finished, but nobody notices — the waiting ticket keeps sitting still
- A date gets promised in planning by someone who doesn't know the chain
What a dependency actually is
Not every connection between two tickets is a dependency. "Belongs to the same topic" is not one. "Cannot start before the other is done" is one.
The test is simple: if the one ticket never gets finished — can the other one still be finished? If the answer is no, it is a dependency. If it is yes, it is a topic, and topics are what tags are for.
More often than people expect, you don't depend on the whole ticket but on part of it. You need the draft from ticket 4, not the signed-off ticket 4. Teams that can express that difference wait unnecessarily far less often.
Three questions a dependency view answers
Once the connections are recorded, they can be arranged in levels: level 1 waits for nothing, level 2 waits only on level 1, and so on. This is not a timeline — everything inside one level can run in parallel.
That view answers three questions that used to be discussion:
- What can someone start today? Everything in level 1. That is the answer to "I'm done, what now?"
- What is the shortest possible runtime? As many steps as there are levels. More people do not make a chain shorter.
- Which ticket holds up the most others? The one with the most outgoing arrows. That belongs first, regardless of how urgent anything else feels.
The circle nobody notices
The nastiest case: A waits on B, B waits on C, C waits on A. None of those three can ever be finished — and because each one looks plausible on its own, you don't spot it by looking.
You can prevent it while recording: a dependency that would close a circle simply doesn't get saved. In grown projects the only cure is to search for them afterwards — and then to report a circle visibly instead of filing it away somewhere.
Where to start
Not with the whole project. Take the five tickets that are open right now and record for each one: what is it waiting for?
For most of them the answer is nothing — good, those can start immediately. For two or three you will find the answer was already in someone's head, just never written down. Those are the win.
If you notice a ticket waiting on four others, by the way, that is rarely a dependency problem and usually a slicing problem. How to split work properly is in Work Breakdown Structure; the most common board mistakes are in 5 Kanban board mistakes.
