Task dependencies

Task dependencies for small teams.

A team of two to ten does not need four relationship types, lead and lag, or a scheduling engine that reflows the plan behind your back. It needs to record one thing — this waits for that — and to be told when the order it has drawn cannot actually happen. This is a practical guide to dependencies at that scale: when to link work and when not to, why the “impossible order” warning matters more than the arrows themselves, and what a critical path really means once you strip the jargon off it.

Try All Do — free

The problem is not drawing arrows. It is noticing when they break.

Every small team already has dependencies. They live in sentences: “we can’t start the build until the flow is signed off,” “QA needs the webhook first.” The plan on the wall almost never records them, so nothing checks them. Then a task slips by three days, the two people downstream do not hear about it, and the miss surfaces a week later as a surprise.

That is the actual failure, and it is worth naming precisely: the cost is not the missing arrow. The cost is that nothing noticed when the order stopped being possible. A plan that can be silently wrong is a plan people stop trusting, and a plan people stop trusting is one they stop opening.

So the useful question for a small team is not “which dependency types should we model?” It is: when this slips, what tells me?

One link type is enough

Formal project management defines four relationships — finish-to-start, start-to-start, finish-to-finish, start-to-finish — plus lead and lag in days. That vocabulary comes from schedules where it earns its keep: concrete cures for three days before the next crew can arrive, and the plan has to say so.

Software and design work overwhelmingly uses one relationship: this cannot start until that is done. Everything else is either a coordination detail two people can settle in a message, or a sign the tasks were drawn at the wrong size. Adopting the full vocabulary costs you a decision on every link, an explanation for every new teammate, and a plan that only its author can read. Take the one type. Skip the rest.

When to link, and when to leave it alone

The most common mistake is not too few links — it is too many. Teams new to dependencies chain every task to the one before it, which turns a plan into a single rigid line where every small change cascades into a full replan. Then they stop maintaining it.

A test that holds up: would this task actually be blocked if the one before it slipped by a week? If the honest answer is “no, it would just be awkward,” that is not a dependency — that is a preference about order, and preferences do not belong in a schedule. Link the handoffs that cross a person or a week. Leave the rest.

Two more to resist:

Linking to express priority. If B matters less than A, that is what order and dates are for. A link says B is impossible before A, which is a much stronger claim.
Linking a task to its own next round. “Design round two waits for design round one” is usually one task with a longer bar and a review in the middle.

The warning is the feature

Once the order is recorded, the plan can be checked against itself. The check is trivial: a task scheduled to start on or before the day its blocker finishes is describing something that cannot happen. Jira calls these off-track dependencies; the name matters less than the fact that something is watching.

This is where most small-team setups quietly fail. A spreadsheet with a “depends on” column records the order but never re-reads it. A whiteboard arrow is right the day it is drawn. Neither notices when someone drags a bar three days to the right — and that is precisely the moment no human notices either.

So the honest requirement for a two-to-ten team is small and specific: record the order, and be told when it breaks. The arrows on the screen are how the tool shows its work — useful, but secondary to the warning.

What a critical path actually is

Strip the jargon and it is one sentence: the longest chain of linked work is the only chain where saving a day moves the finish date. Shorten anything off that chain and the project ends on exactly the same day it would have anyway.

That is why effort and outcome so often come apart. A team can have its busiest week of the quarter and finish no sooner, because all that effort went into work that was never going to decide the date. Knowing which chain you are looking at is most of the value; software that computes it for you is a convenience on top.

Two practical notes for small teams. First, a “critical path” of one task is just the longest task — true, but not an insight. Second, the chain is measured in calendar time, not effort: a five-day task that straddles a holiday and someone’s Friday off occupies more of the runway than a five-day task that does not. If your tool computes the path from effort estimates alone, it is answering a different question than the one you asked.

What the tools do, and what it costs

Dependency support is common; getting it at a small-team price is less so.

Jira. The timeline shows dependencies as lines between bars. Planning across multiple projects, however, lives in Plans, which Atlassian’s own documentation states is “included with Jira Premium and Enterprise” (as of August 2026). For one small team on one board that may not matter; for a team that wants the cross-project picture it is a tier decision, not a setting.
TeamGantt. A genuine Gantt with dependencies, and a free tier — TeamGantt’s pricing page describes getting started with “1 project and 40 tasks” (as of August 2026). Fine for a single plan; a team running a quarter across several efforts will hit the ceiling.
Spreadsheets. Free and infinitely flexible, and the one thing they cannot do is notice. A “depends on” column is a record, not a check.
All Do. One link type, drawn on the timeline, with the impossible-order warning and the critical-path lens included — free.

We keep these figures dated because vendors change them. If you are reading this months later, check the vendor’s own page before quoting us.

How this works in All Do

You draw a dependency instead of filling in a form. Hover a task bar and two small dots appear just past its ends; drag from the right-hand dot onto the task that waits, and the link is drawn as a line between the two bars. Grab the left-hand dot instead and you are asking the opposite question — what has to happen first? — which produces the same link. Clicking a line removes it, with an undo offered in case the click was not what you meant.

The board refuses links it cannot schedule. A loop — A waits for B, B waits for A — has no valid order, so it is declined while you are still dragging, along with duplicates and links to sticky notes, which carry no schedule of their own. You find out before you finish the gesture, not after.

When the order is impossible, the line turns red and dashed, the task’s badge goes red, and the header counts the problem: “2 scheduling issues.” Clicking that steps through the offenders. Nothing is blocked and nothing is silently corrected — the plan stays editable while it is wrong, and says that it is wrong.

When something slips, the board does the arithmetic and offers: “3 dependent tasks now start before this ends — push them.” Accepting moves each one to the first working day after the thing it waits on, around weekends, public holidays, and that person’s time off, and the whole cascade undoes in a single step. It is offered rather than applied, because a planner that silently reflows your board is one you have to double-check every time.

Finally, an optional lens marks the critical path — the longest chain by calendar span, so time off and weekends count — and names it in the header: “critical path: 4 tasks, ends May 1.” It rests off, because it is a question you ask rather than a state you live in.

A ten-minute start

Put this quarter’s work on the timeline first, unlinked. Dependencies drawn before the dates exist tend to encode wishes.
Find the three or four real handoffs — the ones that cross a person and a week — and draw those links only.
Read the header. If it reports scheduling issues, your plan was already impossible; fix the dates now rather than discovering it in week six.
Add the date you are actually aiming at as a milestone, so “on track” has something to be on track for.
Turn on the critical path once. It is usually shorter, and more boring, than the team expects — that is the point.

Open All Do — free

Frequently asked questions

Do small teams actually need task dependencies?

Most of the time, no — and that is the honest answer. A five-person team can hold two or three handoffs in its head. Dependencies start earning their place at the point where a handoff crosses people and weeks: the design has to land before the build starts, the build before the launch checks. Below that, linking every task to the one before it makes the plan rigid without making it truer. The test is simple: would this task actually be blocked if the one before it slipped? If not, do not link them.

What is the difference between a dependency and a deadline?

A deadline is a date somebody promised. A dependency is an order the work itself imposes. They fail differently, so they need different marks on a plan: a milestone is the date, and a link is the order. When the two disagree — the chain now finishes after the date — that is the single most useful thing a planning tool can tell you, and it is the reason to record both rather than keeping the order in your head.

Do I need finish-to-start, start-to-start, and lag?

Almost certainly not. The four relationship types plus lead and lag come from construction and manufacturing schedules, where concrete really does cure for three days before the next crew can start. Software and design teams use one relationship almost exclusively: this waits for that. Every additional type is another thing to get wrong and another thing to explain to whoever inherits the board. All Do ships exactly one: blocks.

What is a critical path, in plain terms?

The longest chain of linked work on the board. It matters because it is the only chain where saving a day actually moves the finish date — shortening anything off it changes nothing at all. That is the whole idea, and it is why "we all worked hard" and "we finished sooner" are so often unrelated. A small team does not need critical-path software to use this; it needs to know which chain it is looking at.

How does All Do handle dependencies?

You draw them. Hover a task bar, grab the dot at its end and drop it on the task that waits — the link is a line between the two bars, and clicking that line removes it. If a task is scheduled to start before the work it waits on has finished, the line and the badge go red and the board counts the problem in its header, because a plan that cannot happen should say so rather than render as though it were fine. When something slips, the board offers to push everything waiting on it in one undoable action, and an optional lens highlights the chain that decides the finish date.