Everyone Was Busy. The Critical Path Wasn't Moving.

In the last post, the login plan finally left my head and hit inboxes. Backend got the auth API and rate limiting. Frontend got the login UI and OAuth. QA got the E2E checklist and an explicit note to wait on both tracks. The dependency graph was right. People knew what they owned.

A few days later, standup sounded fine.

Backend: "Working on session handling and a few auth edge cases." Frontend: "Polishing the login form, wiring OAuth buttons." QA: "Drafting scenarios, setting up the staging checklist."

Tickets moved. Slack was quiet in the good way. Nobody was blocked on their own work. I almost closed the laptop. Something still felt off, so I opened the login timeline instead of logging off.

What the graph showed

The API contract task had one comment from three days earlier and nothing since. Everything that mattered for the sprint still hung off that edge. Frontend could polish a form with nowhere real to land. Backend could tidy session code that wasn't the contract. QA could write scenarios for a handshake that did not exist yet.

They weren't lying. Everyone had real work on their plate. The critical path still had not moved.

I almost shrugged and called the standup clean. Three green updates, no raised hands. Looking at the graph is what stopped me. Same login sprint as the week before, different failure: not "who owns what," but whether we were unblocking the one task that unblocks everyone else.

Activity is not progress

On a small team, standup trains you to collect activity. What did you do yesterday? What are you doing today? Any blockers for you?

Those questions catch a stuck person. They miss a stuck edge.

Critical path, in the boring scheduling sense, is the chain of work that still sets the ship date. For our login sprint, that chain ran through the API contract. Until that edge moved, the polish and the checklist writing filled the day without unlocking QA, and without making OAuth real against a backend instead of a mock.

If your plan is a flat list of tickets, standup is almost all the signal you get. People report their slice. You infer the sprint from how confident everyone sounds. I've seen AI status summaries make that worse. They take the same slice-level updates and rewrite them into a tidy paragraph that sounds like the project is progressing. You get longer sentences and cleaner grammar. You do not get a better read on the blocking edge.

Why standup defaults to a false green

Nobody on that call owned the question "did the blocking edge move?"

Backend reported what they could do without finishing the contract. Frontend reported what they could do against mocks. QA reported prep that helps later and does nothing now. Each update was true. The sprint-level read was wrong.

I've sat through this at other jobs. At one startup we had two weeks of green standups before anyone noticed the integration due at end of quarter had not been touched in ten days. Everyone had been honest about their own ticket. Nobody had been asked whether the thing gating launch had moved.

Looking at the edge

What changed was not a better standup script. I started keeping the login timeline open on a second monitor while people talked.

On a dependency graph, the stuck edge is visible without anyone saying it out loud. I ask one question first: did the API contract move? If no, the rest of the updates are context, not proof the sprint moved.

Ravel does not replace the conversation. It keeps the gating task visible whether or not anyone brings it up, so I stop mistaking a busy call for a moving sprint.

What I ask now

I start standup with the critical path, then hear personal updates.

If the blocking edge moved, the busy work matters and I want to hear it. If it didn't, we talk about that edge before we congratulate ourselves for polishing around it.

If you have a ritual that catches "everyone is busy / nothing that gates the sprint moved" without a graph, I want to hear it. Manual check at the top of standup? One named owner for the blocking edge? Hope and Slack?

We're building this at theravel.app. Take a look, or tell me what you use instead.