Two weeks before PI planning, three teams spent an afternoon at a whiteboard. A sticky note for every feature, a line of red string for every “we need this from you first.” By the end there were 23 arrows, the platform team had pulled two items forward, and the confidence vote came in at four fingers. Someone photographed the wall and put it in Confluence.
Six weeks later the release is nine days late. The arrow that did it isn’t in the photo.
What dependency mapping is for
Dependency mapping is the practice of identifying which pieces of work rely on other pieces, and drawing those relationships so the work can be sequenced. (In IT operations the same term means mapping how applications, services and hosts depend on each other. This article is about the delivery kind: work that cannot finish until other work does.) A project dependency map usually records the blocking item, the blocked item, the owning teams, the dependency type, with finish-to-start the most common, and whether it is internal or external.
Done well, it is one of the most valuable hours in planning. It makes the teams who hold each other’s work say so out loud, and it surfaces sequencing problems while they are still cheap to fix. The map is the team’s engineering judgment about what blocks what, and it feeds the confidence vote directly.
The map is a snapshot
The trouble starts after the vote. A dependency map records the dependencies known on the day it was drawn. Then the work starts, and three things happen that the map cannot show:
- New arrows appear. An integration test shows the reporting feature needs a schema change from another team. Nobody redraws the map for one link.
- Soft arrows turn hard. A link marked “nice to have first” turns out to be load-bearing once someone starts the work.
- Arrows age. The blocker was due in sprint 3. It is now sprint 5. On the map, the arrow looks exactly as it did on planning day.
Even a map kept in a tool shows the arrow, not the days. It says item A blocks item B. It does not say what A’s two-week slip does to the date you committed to. That is the second of the three things that erode a committed release date: dependencies surfaced too late, or surfaced on time and then never priced. Scope creep and capacity changes are the other two, and they usually arrive together.
Keep the map where the work lives, and read it in days
The fix is to stop treating the dependency map as a picture and start treating it as data.
- Record every arrow as a Jira issue link between the actual work items, including links to blockers in another team’s Fix Version. The map is now the links, and nobody has to redraw it.
- Mark which links are hard (the work cannot start) and which are soft (a sequencing preference). Reclassify the moment someone learns more.
- For blockers outside Jira, such as a vendor deliverable or a sign-off, add a placeholder item with the promised date and a named owner, and hard-link it. As with project dependencies in general, the type you assigned at planning never changes; the blocker’s age does.
- At every sync, read one number: the gap in days between the committed date and the forecast at the confidence the team committed at.
An illustration, not customer data. A release is committed for 20 March at 85% confidence. At the vote, the 85% forecast sat at 17 March: three days of margin. In week four a new hard link appears. The reporting feature now waits on a schema change in the data team’s Fix Version, due in sprint 6. The 85% forecast moves to 26 March, six days past the commitment. The 50% forecast is 19 March, so the release reads attention, not yet at risk.
Now the sync has a decision with a number on it. Ask the data team to pull the schema change forward? Move the reporting feature to the next release? Renegotiate the date with the business today? Each of those is still the team’s call, and so is every assumption behind the forecast. What changes is that they make the call in week four, not in week ten.
Where Advanced Release Planning fits
Advanced Release Planning for Jira reads the dependency map you already keep as Jira issue links. Hard links feed a dependency-aware Monte Carlo forecast built on the team’s actual throughput. The Critical Path view shows the ordered sequence of work currently dictating the committed date, including blockers that live in another team’s Fix Version. Circular dependencies are flagged and excluded, and a ranked risk heatmap sorts the items on or near the critical path. The committed date carries its confidence band (50%, 85%, 95%) and stays current as scope, dependencies and capacity move. The team sets the assumptions; the app does the arithmetic at Monte Carlo scale and keeps it live. Release status reads on-track at or above P85, attention between P50 and P85, and at-risk below P50.
If you run PI planning, the same is true of the board on the wall: see why the SAFe program board is a snapshot. For the step-by-step handling of hard links, soft links and external placeholders, see the dependency-aware planning reference doc.
Key takeaways
- Dependency mapping captures the team’s judgment about what blocks what. It belongs in the confidence vote.
- After the vote the map is a snapshot: new links appear, soft links turn hard, blockers age.
- A map shows the arrow, not the days. Keep it as Jira issue links so it stays current.
- Read the gap in days at the committed confidence at every sync, and renegotiate before the slip.
FAQ
What is dependency mapping in project management?
Identifying which work items rely on other work items, and recording those relationships so the work can be sequenced and the blocking teams know what they owe.
What should a dependency map include?
The blocking item, the blocked item, the owning teams, the dependency type, whether it is internal or external, and whether it is a hard gate or a sequencing preference. For a release, add one reading at every sync: what the open dependencies cost the committed date, in days.
How often should a dependency map be updated?
Whenever a dependency changes. That is only practical if the map is the issue links themselves rather than a separate diagram someone has to redraw.
Keep your dependency map. Add the number it’s missing. See the committed date and its live confidence band in Advanced Release Planning, or start a free trial on the Atlassian Marketplace.
2 Comments
Leave your reply.