Stalled Tasks Kill Sprints, Not Deadlines: A Field Guide

A Sprint That Died With Nothing Actually Blocked

Sprints rarely die from a missed date. They die because work quietly stops moving and nobody notices for days. Deadlines get the blame because they're visible. Stalls do the damage because they aren't.

A nine-person B2B SaaS team I spent a week with last spring had a board that looked healthy on day six of a two-week sprint: 34 tickets, 22 marked In Progress, 11 in To Do, one Done. In every standup that week, the answer was the same. Nobody said the word blocked. Nobody was lying, either.

They closed that sprint at 58% of committed work. So we went through the history ticket by ticket, and the picture was ugly. Nine of those twenty-two active tickets were waiting on a single Figma file. Five sat in a review queue owned by one staff engineer who'd spent three days at a conference. Three were waiting on an API key from a vendor whose rep had stopped replying. Five were real work in motion.

Twenty-two tickets looked active. Five actually were. The rest were parked cars with the engines running.

Here's the part that stuck with me: standup wasn't the problem. The board was. Every engineer had done their piece and handed the work off to somebody else, and there was nowhere on that board to say so. So they all said the same true-but-useless thing: it's in progress.

If your team has ever finished a sprint wondering where two weeks went, you've probably lived a version of this. The fix isn't more meetings or more honest engineers. It's admitting that a two-state board, open and closed, can't see the most expensive thing in software: stalled tasks.

Open and Closed Can't Tell You If Work Is Moving

A board with two states answers one question: is this done? It can't tell you whether work is moving, and those are different questions. Teams that surface blocked, waiting, and in-review states usually find their real risk within a week, because most of it was sitting in plain sight.

This isn't a niche idea anymore. GroupBWT's 2026 guidance for software project management recommends surfacing dependency paths, cutting unstructured meetings, and tracking stalls instead of tracking tasks, with prioritization driven by dependency risk rather than arbitrary dates. DX's 2026 guidance pushes the same direction from the other end: async-first workflows, and measurement based on speed, effectiveness, quality, and impact instead of velocity and commit counts.

And the tooling is catching up. AI-enhanced platforms like Jira and Linear are now pitched on predicting sprint delivery and flagging blockers automatically. Fine, but prediction is only as good as the states you feed it. An algorithm can't flag a stall that your workflow refuses to name.

For twenty years, the project-management industry sold status reporting. The report said on track. The work said something else. Ask yourself what In Progress tells you about a ticket that's been in progress for nine days. Nothing. It tells you nobody has touched it. Progress isn't a state. It's a hope.

I've started asking teams a single question: how many of your open tickets are waiting on another human right now? The first answer is always some of them. When we count, it's usually closer to a third. On a ten-person team, that's three people's worth of throughput parked in a queue nobody can see.

The Four Kinds of Stall (and Why One 'Blocked' Flag Fails)

Most stalled work falls into four buckets: hard blocks, review queues, undecided decisions, and unavailable people. Each needs a different fix, which is why a single generic blocked label never survives contact with a real sprint.

1. Hard blocked. The vendor, the infrastructure, the legal review. Name the outside party, set a check-in date. These are rare, loud, and easy to see.
2. Waiting on review. Not work, a queue. A staff engineer with eleven pull requests waiting isn't slow; the system is. Cap the queue, rotate reviewers, or set a target like first response within four working hours.
3. Waiting on a decision. The expensive one. Nobody's calendar is full; the ambiguity is. Undecided work doesn't stay still. It multiplies. Name one decider and one decision date, not a discussion.
4. Waiting on a person. Vacation, conference, a customer fire. Use calendar-aware assignment so nobody routes the critical path through someone who's on a plane.

There's a fifth, sneakier one: waiting on you. The three-minute task you keep not doing while it blocks two other people. That one never shows up in a report, because the ticket is assigned to you and you're definitely getting to it.

The taxonomy matters because the fixes don't overlap. Escalating a review queue to a VP is theatre. Assigning a decider to a hard block is useless, the vendor doesn't care who's in charge. Treat every stall the same and you'll fix none of them.

Dependencies Are the Plan. Dates Are Just a Guess About Them.

A date is an output of dependencies, not an input. When a plan is built from upstream blockers and escalation paths, the schedule becomes a model that updates itself when a vendor slips, instead of a promise you quietly break in week three.

Dates feel like the thing you control because they're the thing you can type. But try this with any deadline your team is carrying: ask why that date exists, and keep asking until you hit something outside the building. A fintech team I talked to had a launch date baked into a customer contract. Their engineers spent three weeks protecting a code freeze that was never the constraint. The real blocker was an auditor's report with a seven-week queue. Nobody had written that dependency down anywhere, because it wasn't a ticket, it was a fact everyone assumed everyone knew.

That's the pattern. If the why behind a date points to something inside your control, the date is real. If it points to a vendor, a compliance cycle, or another team's roadmap, the date is a hope with a calendar entry.

Dependency-aware planning also changes what you work on first. Auto-prioritizing by dependency risk, the thing blocking the most downstream work, beats prioritizing by whoever shouted most recently, and it beats arbitrary dates by a mile. The test is simple: what unblocks the most people today?

This is where deadline flexibility stops being an excuse and becomes math. When the upstream slips, the downstream date moves automatically, with the reason attached, and the person who cares hears about it the same day. The alternative is what most teams do: hold the original date as if it were truth, then explain the miss later. One of those builds trust. The other spends it.

The Waiting Tax Got More Expensive in 2026

Idle work has always cost money through rework and context reload. What's new is that the meter now runs on tokens too, because agents work, and bill, through long stretches of unattended time.

Gartner forecasts worldwide AI spending of $2.59 trillion in 2026, with AI software alone at $453.2 billion. Crunchbase News reported more than 25 billion dollars raised by AI startups in the first two weeks of 2026 across 200-plus funding rounds, including xAI's 20 billion dollar Series E. Money that size doesn't sit patiently in a queue.

Cost governance is now its own product category. 1Password shipped AI Spend and Consumption Management to track token usage and control AI costs across tools like Anthropic, Cursor, and OpenAI. Once your CFO can see the meter, 'we were waiting on a decision' gets a lot less charming.

Meanwhile, agents are getting the memory your project doesn't have. VentureBeat covered Anthropic's Claude Code Projects as an always-on conversation that remembers and delegates long-running dev work. Your agent now holds context for a task that takes three days. The design file, the review, the signature? Those live in somebody's DMs and expire the moment that person goes on holiday.

Agents are getting better memories than the projects they're working on. And as verification becomes the bottleneck in AI-heavy development, review and verification queues only get longer. Which means waiting on a human to check something is about to become the most common state in software, and most boards still don't have anywhere to put it.

A Field Guide for Making Waiting Visible

You don't fix stalls with heroics. You give waiting a name, an owner, and a clock, then review the waiting list once a week instead of the task list every day.

1. Give waiting its own state. Blocked, waiting, in review. Real states with counts, not sticky notes on a monitor.
2. Name the human, not the team. Waiting on Platform is a shrug. Waiting on Dana for the cert is an action.
3. Put a clock on every waiting item. Twenty-four hours quiet triggers a nudge. Five days triggers an escalation. Time-based escalation is a system; frustration-based escalation is politics.
4. Keep synchronous time for ambiguity. Async handles status. Live conversations are for tradeoffs and decisions with a named decider in the room.
5. Let dates follow dependencies. If the upstream slips, the downstream date moves, and the stakeholder hears about it that day, not at the retro.
6. Review stalls weekly, not tasks daily. Ten focused minutes over everything in a waiting state finds more risk than any dashboard you'll ever build.
7. Lower the cost of marking a stall. This is the unglamorous one. If parking a task takes a mouse, six clicks, and a modal, it won't happen at 5:40pm on a Friday. It'll get marked done instead, and the stall goes underground.

That last point is why keyboard-first capture matters more than it sounds. A state only exists if people use it, and people only use states that cost them nothing. Two keystrokes to park a task with the right owner and the right reason is the difference between a board that reflects reality and a board that reflects optimism. The same logic applies to async-first workflows in general: the tooling has to be faster than the meeting it replaces, or the meeting wins.

What Comes Next: Projects That Know How to Wait

Agents will need stall states of their own, waiting on human approval, waiting on CI, waiting on a rate limit. The next round of project tooling will be judged less on how fast it can plan and more on how honestly it can report that nothing is moving.

Because an agent that can't tell you it's stuck is just a more expensive way to be stuck. The teams that win the next two years won't be the ones with the fastest models. They'll be the ones who can answer, in a single keystroke: what's waiting, on whom, and for how long? Get that right and the deadlines get easier. Keep guessing, and you'll close another sprint at 58% and call it a mystery.