The 4 Jira Dependency Types: FS, SS, FF, and SF Explained

Ask most Jira users what a dependency is and they will describe one relationship: this task has to finish before that one can start. That is correct, but it is only one of four dependency types — and the other three are where real project schedules get their nuance.

Formal project scheduling recognises four ways two tasks can relate: Finish-to-Start (FS), Start-to-Start (SS), Finish-to-Finish (FF), and Start-to-Finish (SF). This page is the plain-English reference for all four: what each means, the notation, when to reach for it, and — crucially — how Jira actually handles it, because Jira only understands one of them out of the box.

Quick Reference

Type	Notation	Rule	Plain English
Finish-to-Start	FS	B starts after A finishes	”Do A, then do B.”
Start-to-Start	SS	B starts after A starts	”Start B once A is underway.”
Finish-to-Finish	FF	B finishes after A finishes	”Wrap up B no earlier than A.”
Start-to-Finish	SF	B finishes after A starts	”Keep B going until A begins.”

In every case, A is the predecessor and B is the successor. The two letters read predecessor-first: the first letter is the point on A that matters, the second is the point on B it controls. “Finish-to-Start” = A’s finish gates B’s start.

Finish-to-Start (FS)

Task B cannot start until Task A finishes.

This is the default and by far the most common type — the intuitive “do this, then that” chain. Examples in a Jira project:

• Testing cannot start until development finishes
• Deployment cannot start until testing passes
• Onboarding docs cannot start until the feature is code-complete

FS relationships build the sequential backbone of most schedules. This is the only type Jira handles natively: create an issue link and Jira’s Timeline draws it as an FS arrow. Everything below, Jira cannot represent as a scheduling constraint.

Start-to-Start (SS)

Task B cannot start until Task A starts.

Use SS when two tasks share a trigger and run in parallel, rather than one waiting for the other to complete. Often paired with a lag (“B starts two days after A starts”). Examples:

• Frontend and backend build both kick off once the design hand-off happens
• A tech writer shadows development — documentation starts when coding starts
• QA environment setup begins as soon as the first development sprint begins

SS is how you model concurrent work with a common starting gun. In Jira, you can create a custom “starts with” link, but the Timeline will not schedule it — the two tasks are treated as unrelated for date purposes.

Finish-to-Finish (FF)

Task B cannot finish until Task A finishes.

FF is the quality-and-review workhorse: two tasks can overlap while running, but they must conclude together. Examples:

• Testing cannot finish until the last bug fix is merged
• Documentation review cannot finish until the feature code is frozen
• Integration testing cannot finish until every component test finishes

FF keeps related work synchronised at the end rather than the start. Like SS, it is invisible to Jira’s Timeline — nothing stops Jira from marking B done while A is still open.

Start-to-Finish (SF)

Task B cannot finish until Task A starts.

The rarest type, reserved for just-in-time and transition scenarios where coverage must continue until a replacement is live. Examples:

• The legacy system cannot be decommissioned (finish) until the new system goes live (start)
• A temporary workaround stays active until the permanent fix ships
• Night-shift coverage cannot end until day shift begins

SF is uncommon in software delivery but essential in migrations and operations planning. Jira has no concept of it at all.

Lag and Lead Time

Any of the four types can carry a lag (a delay) or a lead (an overlap):

• Lag: “B starts three days after A finishes” (FS + 3d lag) — useful for cure times, review windows, or shipping delays.
• Lead: “B starts two days before A finishes” (FS − 2d lead) — useful when the successor can begin on the predecessor’s partial output.

Lag and lead let you model reality without inventing filler tasks. Jira’s native links have no lag/lead concept, so any buffer has to be baked into dates manually — where it silently drifts out of sync the moment something moves.

Why Jira Only Handles Finish-to-Start

Jira supports dependencies through issue links, and you can even define custom link types. But the scheduling engine behind Jira’s Timeline only interprets one relationship — Finish-to-Start — as an actual date constraint. Create an SS, FF, or SF link and Jira records the relationship on the issue, yet the Timeline neither draws it nor propagates dates through it. In practice, Jira collapses every dependency into “these happen in sequence,” which throws away the parallel and transition logic that SS, FF, and SF exist to capture.

There is also no propagation, no lag/lead, no critical path, and no validation — so even the FS links you do create will not warn you when an upstream slip has made a downstream date impossible. For the full breakdown of what native Jira can and cannot do with dependencies, see the complete guide to tracking dependencies in Jira.

Showing All Four Types on a Gantt Chart

A Gantt chart stores the dependency type per link, so all four relationships become real scheduling constraints instead of a single flattened “sequence.” With Simple Gantt, each link on the timeline knows whether it is FS, SS, FF, or SF, carries any lag or lead you set, and propagates dates through the correct rule when a task moves. That means:

• SS and FF render as their own connector shapes, so parallel and synchronised-finish work is visible at a glance
• Dates propagate through the actual relationship — move a predecessor and every successor recalculates by its own type
• The critical path is computed across all four types, not just FS, so the chain that truly drives your deadline is correct
• Validation catches circular chains and impossible date combinations before they reach your schedule

Because Simple Gantt is built on Atlassian Forge, it reads your Jira issues directly — the dependency types you set live alongside your real data, with no export or sync step. See the full capability set on the dependency management feature page.

Which Type Should You Use?

A quick decision guide:

• One task must fully complete before the next begins? → Finish-to-Start (FS)
• Two tasks should run together once one kicks off? → Start-to-Start (SS)
• Two overlapping tasks must wrap up together? → Finish-to-Finish (FF)
• Something must stay active until a replacement starts? → Start-to-Finish (SF)

When in doubt, it is almost certainly FS — it covers the large majority of real dependencies. Reach for SS, FF, and SF deliberately, when the work genuinely overlaps or transitions. Model them accurately and your schedule reflects how the project actually runs; flatten everything to FS and you inherit the same blind spots Jira’s Timeline has.

Support for SS, FF, and SF is one of the clearest dividing lines between Jira Gantt apps. For how each one handles them, see the best Gantt chart plugins for Jira compared, or the head-to-heads with BigGantt, Structure.Gantt, and WBS Gantt-Chart.