Eight teams down the left side. The same eight across the top. Fifty-six cells that matter, and at PI planning the release train filled in fourteen of them: Payments needs a token change from Identity, Search needs the new index from Platform, Mobile needs both. Every blank cell was a conversation too: “No, we don’t need anything from you this increment.” The confidence vote came in at four fingers.
Five weeks later the release is a week late. The cell that did it was blank on planning day.
What a dependency matrix is
A dependency matrix is a square grid with the same list on both axes: teams, features or components. Read across a row to see what that item needs from the others. Read down a column to see who needs that item. A mark in a cell means a dependency exists. Pairs of marks mirrored across the diagonal mean two items need each other, which is a cycle. In systems engineering the same tool is called a dependency structure matrix (DSM), and software architects use it to show coupling between code modules. This article is about the delivery kind: a project dependency matrix of work that cannot finish until other work does.
Teams like it for a good reason. It is dense. Eight teams produce 56 possible relationships, and the grid shows all of them on one screen, including the ones that were checked and ruled out. A blank cell is a decision, not an omission. Filling the grid is expert engineering judgment about who owes what to whom, and it feeds the confidence vote directly.
A cell holds a mark, not a date
The matrix is right on the day it is filled in. After the vote, three things happen that a cell cannot show:
- Blank cells fill. An integration test shows Payments needs a token-refresh change from Identity after all. Someone types an X into a spreadsheet tab, or nobody does.
- Marks age. The blocker was due in sprint 3. It is now sprint 5. The X looks exactly the same.
- Marks change weight. A cell is binary. A sequencing preference and a hard gate get the same X, until the preference turns out to be load-bearing.
None of those changes moves anything else in the grid. A new mark does not re-run the forecast. An old mark does not turn red when its blocker slips. That is the second of the three things that erode a committed release date: dependencies surfaced too late, or surfaced on time and never priced. Scope creep and capacity changes are the other two, and they rarely arrive alone.
Turn the cells into links, and read the grid in days
Keep the matrix as a planning conversation. Stop using it as the record.
- Name the work behind each mark. A team-to-team cell usually stands for two or three specific items. Record each one as a Jira issue link between the actual work items, including blockers in another team’s Fix Version.
- Give each link a weight. Hard if the work cannot start without it, soft if it is a preference. Reclassify the moment someone learns more.
- Fill new cells the same day. When a blank cell turns out to be a dependency, add the link then, not at the next planning event. For a gate outside Jira, such as a vendor drop or a sign-off, add a placeholder item with the promised date and a named owner, and hard-link it.
- Read one number at every sync: 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 14 April at 85% confidence. At the vote, the 85% forecast sat at 10 April: four days of margin. In week three the blank Payments-to-Identity cell fills. The token-refresh change is hard-linked and due in sprint 5. The 85% forecast moves to 21 April, seven days past the commitment. The 50% forecast is 13 April, still inside it, so the release reads attention, not yet at risk.
Now the sync has a decision with a number on it. Ask Identity to pull the change forward? Ship Payments without token refresh and follow up? Renegotiate the date with the business this week? Each is still the team’s call, and so is every assumption behind the forecast. What changes is that the call happens in week three, not week nine.
Where Advanced Release Planning fits
Advanced Release Planning for Jira reads the dependencies you record as Jira issue links. It does not import a matrix, and it does not put a number of days on an individual cell. 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, and cross-release context nodes put blockers from another team’s Fix Version, the off-team cells of your matrix, directly in that path. Cycles are detected, 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: which throughput window, whose capacity, what is in scope. The app does the arithmetic at Monte Carlo scale and keeps it live. Status reads on-track at or above P85, attention between P50 and P85, and at-risk below P50.
If your team draws the same relationships as a diagram rather than a grid, see why dependency mapping draws the map once, and how project dependencies get typed at planning and priced too late. For the step-by-step handling of hard links, soft links, cycles and external placeholders, see the dependency-aware planning reference doc.
Key takeaways
- A dependency matrix records the team’s judgment about who needs what from whom, including what was ruled out. It belongs in the confidence vote.
- After the vote, blank cells fill, marks age and marks change weight. The grid shows none of it.
- Turn each mark into Jira issue links between real work items, weighted hard or soft.
- Read the gap in days at the committed confidence at every sync, and renegotiate before the slip.
FAQ
What is a dependency matrix in project management?
A square grid with the same teams, features or components on both axes. A mark in a cell shows that the row item depends on the column item. It is also called a dependency structure matrix (DSM).
How do you read a dependency matrix?
Across a row for what that item needs, down a column for who needs it. Marks mirrored across the diagonal indicate a cycle that has to be broken before the work can be sequenced.
Dependency matrix or dependency map: which should we use?
The matrix is better for seeing every possible pair, including the ruled-out ones. The map is better for following a chain. Both are snapshots, so record the result as issue links and read what the open dependencies cost the committed date, in days.
Keep your dependency matrix. 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.
Leave a Reply
Your email is safe with us.