The Status That Lies
"In Progress" is the most dangerous status in any task tracker.
Not because your team is lazy. Not because they're hiding problems. But because "In Progress" is a single state that maps to about a dozen different realities:
From the outside, all of these look identical. That's the problem.
The Hidden Idle Time Study
Research across engineering organizations consistently finds the same pattern: the average task in "In Progress" is actually *actively worked on* for less than 30% of its calendar time. The rest is queuing, waiting, context-switching, or simply forgotten.
Think about what that means for a "2-week sprint task":
Your burndown chart shows steady progress. Your status says green. Your release date is a guess.
The Anatomy of a Blocked Task
Here's what a typical high-risk "In Progress" task looks like when you look at the data underneath:
Day 1-2: Developer picks up the ticket, starts coding. Git shows commits. Good.
Day 3: Developer gets pulled into an incident review. No commits. Tracker: "In Progress."
Day 4-5: Back on the ticket, hits an architectural question. Slack message sent, waiting for answer. No commits.
Day 6: Answer received, coding resumes. But the sprint is 60% done and this "simple" task is barely started.
Day 7-8: Feature coded, but there's a complex merge conflict. PR gets delayed.
Day 9: PR opened. Two reviewers tagged, neither has bandwidth. PR sits.
Day 10 (sprint end): "90% done, carries over."
None of this was invisible. All of it was measurable in real time. The question is whether you had the tools to see it.
Making the Invisible Visible
The solution isn't more status meetings. It's instrumenting the actual work:
1. Commit frequency drops — developer may be blocked or pulled away
2. PR age — review bottleneck or missing context
3. Task age by stage — where do tickets pile up in your workflow?
4. Cross-team dependency tracking — what's waiting on someone outside your team?
When you can see this in real time, you can intervene *before* the carry-over conversation, not after.
Changing the Status Culture
One practical change: add a "Waiting" status to your workflow. Make it socially acceptable — even encouraged — to move a ticket to "Waiting" when you're blocked.
"In Progress" should only mean: a developer is actively working on this right now. When that stops being true, the status should change.
Simple? Yes. But it requires a culture where flagging a block isn't admitting failure — it's sharing signal that helps the whole team move faster.