Why do tasks get stuck in progress?

The card is a whole project wearing a task's name

The most common reason a task will not finish is that it was never really a task. It is a project in disguise, and a project does not move cleanly through a single column. The tell is that you cannot picture the moment it gets marked done. If you ask the owner what is left and the answer is a list rather than a single thing, the card is too big, and it has been in progress for a week because there is always something else still to do.

The fix is to stop treating it as one card. We split it into smaller pieces that can each be finished and checked off on their own. A card called design the onboarding flow never moves, while write the welcome screen copy, build the empty state, and set up the first email each finish in a day. Small tasks have the useful property of being either done or not done, with very little middle ground, so a board full of them reflects real progress instead of hiding the lack of it.

It is blocked, and the board is not saying so

A lot of stuck cards are not stuck at all inside the owner's head. They know exactly what is holding things up, a missing asset, an answer from a client, a dependency on another team, but that knowledge lives with them and not on the card. To everyone else the task simply looks slow. The tell is a card that has not moved and has no recent comments, owned by someone who, when you ask in passing, answers instantly and a little defensively about what they are waiting for.

The fix is to make blocked a visible state rather than a private fact. We add a blocked tag or a short comment naming exactly what the card is waiting on and who can clear it. That does two useful things at once. It stops the rest of the team quietly assuming the owner is behind, and it turns a vague delay into a specific ask with a name attached. Surprisingly often you can clear a blocker without a meeting just by making it visible, because the person who could unblock it never knew they had become the bottleneck.

We watched this play out recently. A card had sat untouched for over a week, and most of us had quietly filed it under slow. When someone finally asked, the owner had been waiting on a single approval from another team since the second day and had assumed a comment somewhere already flagged it. One tagged name later, it moved. The work was never slow. The waiting was just invisible, and invisible waiting looks identical to laziness on a board, which is unfair to the person doing everything right except saying so out loud.

It is parked on someone who does not know they are holding it

Some tasks are finished, or nearly finished, and only waiting on a review, a sign-off, or a decision nobody has made. The work is done; the card is not, because the next move belongs to a different person. These are the most frustrating of all because they feel like progress and produce none. The tell is a card whose last update is the owner writing something like ready for review, followed by a long, patient silence while everyone assumes someone else is handling it.

The fix is to name who owes what, plainly and on the card. Waiting for feedback is not an owner. Sam to approve the copy by Thursday is. This is where clear ownership matters far more than people expect, and it is worth being strict that every task has one clear owner who stays responsible for moving it, even when the immediate next step is someone else's. That owner's job is not to do the pending work, it is to chase the decision, which is a very different habit from waiting politely for it to turn up on its own.

Nobody agreed what finished actually means

A task can sit at ninety percent forever when done is a matter of opinion. One person thinks a feature is finished when it works. Another thinks it is finished when it is tested, documented, and shipped. The card cannot cross the line because the people looking at it have drawn the line in different places. The tell is a task that seems complete every time you check on it but never quite moves, or one that bounces back into progress the moment someone else takes a proper look.

The fix is to agree what done means before the work starts, not after it drags. Even a rough shared definition of done, a line or two on what has to be true for the card to move, removes most of this. It does not need to be heavy process. For plenty of our cards it is a single sentence sitting in the description. The point is only that the owner and whoever reviews the work are aiming at the same target, so the card finishes once instead of being declared finished three separate times.

There is no obvious next thing to do

The quietest kind of stuck is a card that is genuinely live work with no clear next step. The owner opens it, is not sure what to do first, closes it again, and picks up something easier without quite deciding to. Nothing is blocking it and it is not too big, it just does not tell you where to start. The tell is a card with a broad title and an empty description that has been in progress far longer than its size can explain, quietly losing every contest for attention against tasks that are easier to begin.

The fix is small and a little boring: write the next action down. Not the whole plan, just the single next physical thing. Draft the reply, call the vendor, review the open pull request. A task with a concrete next step is easy to pick up in the five spare minutes people actually have, while a task that first requires you to work out what to do gets skipped every single time. Most cards that stall for no visible reason are stalling on exactly this, and it happens to be the cheapest cause to fix.

Catching a stalled card before it becomes a stalled month

The reason we can name these causes quickly is that we look for them on purpose, and early, rather than discovering them when something is already overdue. Once a week someone scans the in progress column for anything that has not moved in a few days and asks a single question about each one: which of these is it? Too big, blocked, waiting on a person, undefined, or missing a next step. That is usually enough to unstick a card while the delay is still measured in days instead of weeks.

The same sweep is a good moment to spot who is overloaded, because a person carrying too many cards produces stuck tasks whether or not any single one has a real problem of its own. When everything is half-started, nothing finishes, and the cause is the workload rather than the work. That one is worth catching early too, since no amount of clarifying a card helps a person who has ten of them open at once.

Here is the honest limit of all this. A board can tell you that a task is stuck. It cannot tell you why. Every signal above, the age of a card, the absence of comments, a vague owner, a missing definition, is a hint and not a diagnosis. The board narrows it down, but a person still has to ask the owner what is actually going on, and we have found no reliable way around that. We have stopped looking for one, because a two minute conversation prompted by a board that flagged the right card is a genuinely good outcome. The value was never automation. It is asking the right question about the right task before it has been quietly dead for a month.