The dependency was on the board at PI planning. Red string, two sticky notes, a label that read FS — API contract from Platform, sprint 3. Everyone saw it. The team discussed it, accepted it and voted four fingers on the commitment with it in view.
In sprint 5 the contract still had not landed. The label had not changed: still finish-to-start, still external, still mandatory. What had changed was its age, and nobody had a field for that.
What project dependencies are
Project dependencies are relationships between pieces of work where one cannot start or finish until another does. Planning practice describes them in two ways.
By logic, there are four types of dependencies in project management:
- Finish-to-start (FS): B cannot start until A finishes. The most common type by far. Example: the payment screen cannot be built until the payment API contract is final.
- Start-to-start (SS): B cannot start until A starts. Example: documentation starts once development starts.
- Finish-to-finish (FF): B cannot finish until A finishes. Example: testing cannot close until the last fix is merged.
- Start-to-finish (SF): B cannot finish until A starts. Rare. Example: the old system stays live until the new one is switched on.
By category, dependencies are mandatory (built into the work itself) or discretionary (a preferred order the team chose), and internal (inside the team or project) or external (another team, a vendor, a sign-off). Task dependencies sit at the lowest level of the plan; project dependencies are the same relationships seen across the whole release.
This vocabulary is useful. It tells you how work connects, which is exactly what a team needs to know when it sequences a release and decides how confident to be.
The type goes into the vote. The cost comes later.
When a team commits to a release date, the confidence vote is expert engineering judgment. The engineers in the room priced the scope, their capacity and the dependencies they could see, including how each one connects and who owns the other end. On the day of the vote, that judgment is the best information anyone has.
Then the release starts, and the dependency picture keeps moving while the vote stays fixed:
- A known blocker ages. The type is unchanged, but the work behind it has waited three sprints instead of one.
- New links appear. Refinement splits a story and uncovers a dependency on a shared service nobody listed at planning.
- Discretionary becomes mandatory. A preferred order turns into a hard one when the workaround falls through.
None of these change the type column in a dependency register. All of them change the date. That is the second of the three things that erode a committed release date: dependencies surfaced too late, or surfaced on time and left unpriced. The other two, scope creep and capacity changes, often arrive with it. A new dependency usually comes with new scope, and the person waiting on a blocker gets pulled onto other work.
Why a dependency register can’t tell you how late you are
Most teams track project dependencies in a register, a RAID log, a program board or Jira issue links. Each records that a dependency exists and what kind it is. None of them says what it costs the committed date, because that depends on things the register does not hold: how much in-scope work sits behind the blocker, how fast the team actually delivers, and how much room is left between the forecast and the commitment.
So the dependency is visible and its price is not. A label that says “external, FS” reads the same in sprint 2 and sprint 6. The external dependencies and cross-team dependencies in release planning that slip releases are rarely unknown. They are known and unpriced.
Read the dependency in days
Advanced Release Planning for Jira keeps the committed date next to a live forecast. Monte Carlo simulation runs on your team’s own Jira throughput and draws a 50/85/95% confidence band around the release. The team still owns the assumptions: which throughput window is representative, whose capacity counts, what is in scope. The app does the arithmetic at a scale no planning meeting can, and keeps it current.
For project dependencies, that works through the links you already keep in Jira:
- It reads blocking links on in-scope work, including links to issues in other teams’ projects, and how long each has been unresolved.
- Blocked work is treated as not yet startable, and the forecast re-runs.
- The movement is reported in days and attributed to dependencies, separately from scope and capacity, so the team can see which of the three is moving the date.
- Release status changes from on-track to attention or at-risk when the committed date falls below the confidence level the team chose.
An illustration, not customer data: a release committed for 5 December at P85. The Platform API contract, finish-to-start, was due in sprint 3. At the end of sprint 4 it is still open, with six in-scope stories behind it. The forecast now shows the release four days later at P85, attributed to dependencies, and the status moves to attention. That is the cue to act while there are still options: ask Platform for a partial contract, re-sequence the six stories, move one below the MoSCoW cut-line, or re-commit to a new date with its confidence stated.
Keep the types. Add the price.
Classifying project dependencies is good planning, and it belongs in the vote. What the classification cannot do is age. Record each dependency as a blocking link in Jira, keep the type in your register if it helps, and let the forecast say what each one costs the committed date today. The dependency reference doc lists what the app reads and what it does not.
Key takeaways
- Project dependencies are typed by logic (FS, SS, FF, SF) and by category (mandatory or discretionary, internal or external).
- The type is fixed at planning. A blocker’s age, and new links found later, are what move the committed date.
- A live forecast reads blocking links in Jira and reports dependency-driven movement in days, separately from scope and capacity.
FAQ
What are the four types of dependencies in project management? Finish-to-start, start-to-start, finish-to-finish and start-to-finish. Finish-to-start is the most common.
Does Advanced Release Planning create dependencies for us? No. It does not create, infer or suggest issue links, and it does not forecast the other team’s delivery date. Dependencies must be recorded as Jira issue links to be read.
Put a number on the next blocker
Before the next dependency ages another sprint, see what it is costing your committed date. See the committed date and its live confidence band in Advanced Release Planning, or try it on your own Jira data from the Atlassian Marketplace.
1 Comment
Leave your reply.