DepMesh for JiraFunctional documentation

What is DepMesh

DepMesh makes cross-team dependencies visible inside Jira: who needs something, who delivers it, which sprint each end falls in, and how much margin (or delay) sits between them. It is the digital version of the classic SAFe PI Planning program board — sticky notes joined with string — but derived live from your real Jira data.

Open it from Jira's sidebar: Apps → DepMesh. Available in English and Spanish (picked automatically from your browser language).

Key concepts

Two-end dependency

Every dependency joins two Jira issues and is drawn with two nodes:

• Needs (solid border): the blocked issue — it needs another team to deliver something.
• Delivers (dashed border): the blocking issue — its team must deliver to unblock the other one.

A curve joins both nodes, its arrow pointing at the one in need: the deliverable flows toward the need.

Gap

The gap measures the distance in sprints between the sprint where something is needed and the sprint where it is delivered:

• +1 positive or zero gap: delivery lands on time or with margin. All good.
• −1 negative gap: delivery lands AFTER it is needed. Risk — renegotiate sprint or scope.
• — no gap: one end has no sprint; it cannot be measured yet.

Uncommitted

When the delivering issue has no sprint assigned, the delivery is uncommitted: nobody has said when it will arrive. These dependencies show in the hatched column on the right edge of the board and are the first to resolve during PI Planning.

Where the data comes from

• DepMesh never invents or duplicates data: it reads Jira's native "Blocks" / "is blocked by" issue links and each issue's Sprint field. Jira is always the source of truth.
• To create a dependency (for now) use the Jira issue itself: Link → "blocks" toward the issue that becomes blocked. Reload DepMesh and it appears.
• Team = project: each board row is a Jira project.
• If an issue has several sprints (history), DepMesh picks the most relevant: the active sprint; otherwise the nearest future one; otherwise the last closed one.
• Permissions: DepMesh reads with your permissions. If you cannot see an issue in Jira you will not see it here; if a link points to something you cannot see, a warning is shown instead of half-truths.

How to read the board

The board is a teams × sprints blueprint:

• Rows: one lane per team.
• Columns: sprints in chronological order, dates under each name. At the far right, the hatched "Uncommitted" column (only when needed).
• Nodes: every dependency draws its two cards — solid where it is needed, dashed where it is delivered — in the matching (team, sprint) cell. The corner label (NEEDS / DELIVERS) confirms the role.
• Curves: run from delivery (○) to need (▶). Red when delivery arrives late; grey dotted when a sprint is missing.
• Gap badge: the label on each curve (green/red/—) is that dependency's gap.

Interaction

• Hovering a node highlights its pair and curve while dimming the rest — handy with many crossing curves.
• The node tooltip shows the full key and summary.
• The board is compact so it fits within the page; if it is still wider than the screen (many sprints), it scrolls horizontally within its own area.

Note: an issue participating in several dependencies appears once per dependency (each curve owns its two ends).

Creating and managing dependencies

New dependency

The + New dependency button opens a dialog with two search boxes: who needs (will be blocked) and who delivers (blocks). Type 2 letters or a key (e.g. EQA-3) and pick from the list. A confirmation sentence (“X delivers to Y”) is shown before creating. On confirm, DepMesh creates the real "Blocks" link in Jira in your name — also visible from the issue itself.

Commitment states and notes

Click any node on the board (or table row) to open the dependency panel:

• Proposed (grey) — detected, no agreement yet.
• Committed (blue) — the delivering team has committed.
• At risk (amber) — committed but in danger. Deliberately different from the negative-gap red: they are different warnings.
• Delivered (green) — resolved.

The state paints a colored strip on the left edge of both nodes of the dependency. Notes hold agreements and conditions. The panel shows the last update.

Where it is stored

State and notes are DepMesh metadata (they never touch the issue) and live inside the Atlassian boundary. If the link is deleted in Jira, the dependency disappears from the board and its metadata cleans itself up on the next load.

Acting on sprints

Beyond reading, DepMesh lets you adjust the ART plan without leaving the board. Every write happens in your name (honoring Jira's permissions and audit trail). DepMesh only moves, creates and edits (name/dates): it never starts, closes or deletes sprints.

Move an issue's sprint

Drag a board node to another sprint of the same team (an existing sprint column, or a team sprint that doesn't have a column yet). DepMesh asks for confirmation before moving. Since the sprint belongs to the issue, if that issue appears in several dependencies all its copies move at once (the dialog warns you). Active or future sprints only; moving to the backlog or to another team isn't supported.

Create empty sprints

The "＋ New sprint" button opens a two-step dialog: name and optional dates, and — team by team — which Scrum board to create it on. A confirmation screen summarizes what will be created before anything happens. Sprints are created empty and serve as move destinations. If a board rejects creation (permissions), the others still proceed and the result is reported per team.

Edit a sprint

The "✎ Edit sprint" button opens a dialog listing future sprints by name ("Sprint 1", "Sprint 2"…). A board sprint is shared across the ART, so you don't pick a team: changing the name or dates applies to all teams that have that sprint (the dialog tells you how many). Only future sprints, only name/dates; if it fails for one team (permissions), the others are still updated.

See the team's full cadence

The "Show the team's empty sprints" toggle (in Configuration, off by default) adds each team's active/future sprints as columns even before they have dependencies — handy to see the whole PI or to prepare move destinations. If a team has several Scrum boards, a dropdown lets you choose which board contributes its sprints (default: all). With the toggle off, the board doesn't change.

Filters and project view

Choosing what you see

• Projects: the "Projects" dropdown limits the board to the teams you pick. The selection is remembered per user across sessions. "All" clears it.
• Sprints: chips per ART sprint (plus "Uncommitted"). A dependency shows if either of its ends falls in the chosen sprint.
• State: chips per commitment state, including "No state". They combine with sprint chips.
• The "x of y visible" counter and "Clear filters" appear when filters are active.

Aligned ART sprints

Even though each team owns its own "Sprint 1" in Jira, when they share name and start date DepMesh shows them as a single column: the PI cadence. The gap is measured on that cadence. A team running misaligned (different dates) gets its own column — deliberately visible.

DepMesh inside your project

Besides the global view (Apps → DepMesh), every project gets a DepMesh tab showing only the dependencies that project participates in ("Project view: X"). There is no project selector there: the host project rules.

Board title and source

Board header

At the very top, the page shows the board name you saved in the configuration (or a placeholder example if you haven't named it yet). It's no longer edited right there: to change the name you open the configuration view.

Configuration view

The ⚙ Configuration button opens a dedicated view that replaces the board while you use it (a "Back to board" button returns you to the normal view). There you can edit:

• Title of the board (e.g. the ART's or the quarter's).
• Description — a free, optional note about this board (what it's for, which teams it covers, etc.).
• Data source: the Projects | JQL switch — see below.

At the bottom of the view you'll see the Created and Last edited dates for this configuration (in your local date/time format, or "—" if it has never been saved yet). Everything — title, description, source and dates — is remembered per user.

Projects or JQL

Inside the configuration view you choose how the board is fed with a Projects | JQL switch:

• Projects (default): the usual selector — pick which projects you want to see.
• JQL: type your own filter (e.g. by fix version, label or team) in a free text field. DepMesh always adds, automatically and visibly noted under the field, the condition AND issueLinkType = "Blocks": however broad your filter is, the board only ever shows real dependencies, never loose issues.

If the JQL you type is invalid, DepMesh warns you next to the field and keeps the previous board on screen — it never goes blank because of a syntax error.

Table view

The BOARD | TABLE switcher (top left) toggles a flat table view: one row per dependency with team, issue and sprint for each end, plus its gap. Useful for long lists or copying keys.

Warnings and states

• No dependencies: when no "Blocks" link is visible, the page says so and explains how to create the first one.
• Warnings (yellow box): link ends you cannot see (permissions or other projects), results truncated by volume, or issues with unexpected format. Partial data is never shown silently.
• Error: if Jira does not respond you get the technical detail and a Retry button.

Quality and availability

• When filters hide every dependency, the page says so and offers to clear them (distinct from "no dependencies").
• States and notes are protected: they are only cleaned when the link has truly disappeared from Jira, never due to filtering or permissions.
• The whole interface exists in Spanish and English, with automated verification that no translation is missing.
• DepMesh runs entirely inside the Atlassian boundary (Forge) with the Runs on Atlassian badge: zero data egress, no external APIs and no third-party analytics.

Glossary