RA-09

Sankey Flow Data — Resource-Issue Assignment Map

Resource Allocation

Default severity: medium
ProcessOutputRiskEffort

What it detects

Generates the complete data structure for the Resource-Issue Sankey diagram. This is a computation output rule (no finding) that computes the bi-directional flow between team members, issue types, epics, and workflow stages. The diagram shows: who works on what epics, what proportion of each person\'s effort goes to each type of work, and which issues flow through which people as they progress through stages. Precious (bottleneck) resources are visually highlighted by flow width. // SOURCE NODES: team members (grouped by tribe/squad if configured) // TARGET NODES: epics, then issue types, then workflow stages // EDGE WEIGHT: hours_logged by person to issues in that epic/type/stage

Detection formula

FOR each_person P: FOR each_epic E: flow(P -> E) = SUM(worklog.time_spent WHERE author=P AND issue IN E.children) FOR each_issue_type T: flow(P -> T) = SUM(worklog.time_spent WHERE author=P AND issue.type=T) FOR each_stage S: flow(P -> S) = SUM(worklog.time_spent WHERE author=P AND issue was IN status=S DURING worklog.date) Bottleneck_score(P) = person_share_of_critical_path(P) * flow_concentration_index(P) Sankey_nodes = \[people, epics, issue_types, stages\] Sankey_edges = \[flow(source, target, weight, bottleneck_score)\] Output: JSON suitable for D3 Sankey rendering **Info** Jira worklog (author + hours + issue + timestamp) + epic hierarchy + changelog (status during worklog) Resource Allocation **RA-10** **Precious Resource Protection Score** Computes a composite \'precious resource\' score per team member that quantifies their irreplaceability and the delivery risk if they become unavailable. Combines: critical path dependency (RA-01), skill silo ownership (RA-06), worklog dominance across epics (RA-02), and WIP load (RA-03). The score is used to rank resources by risk and highlight them in the Sankey diagram. FOR each_person P: critical_path_share(P) = person_share_of_critical_path(P) // RA-01 output skill_silo_count(P) = COUNT(skill areas where P is sole owner) // RA-06 output epic_dominance_count(P) = COUNT(epics where P has >40% worklog share) // RA-02 output current_wip(P) = COUNT(active_assigned(P)) // RA-03 output precious_score(P) = ( critical_path_share(P) * config.ra.precious_weight_critical_path // default: 40 + MIN(skill_silo_count(P), 5) / 5 * config.ra.precious_weight_skill_silo // default: 30 + MIN(epic_dominance_count(P), 4) / 4 * config.ra.precious_weight_epic_dom // default: 20 + MIN(current_wip(P) / config.ra.person_wip_limit, 2) / 2 * config.ra.precious_weight_wip // default: 10 ) // score 0.0 - 1.0 IF precious_score(P) > config.ra.precious_flag_threshold // default: 0.65 THEN FLAG precious_resource_at_risk IF precious_score(P) > config.ra.precious_critical_threshold // default: 0.80 THEN CRITICAL — loss of this person would halt delivery Report: ranked precious resource list; knowledge transfer recommendations

Examples in practice

  • One person owns a disproportionate share of critical-path or high-WIP work.
  • Delivery risk rises when a single expert becomes the throughput bottleneck.
  • A team shows generates the complete data structure for the resource-issue sankey diagram while precious weight critical path is set to 40 + MIN(skill_silo_count(P), 5) / 5 * config.ra.precious_weight_skill_silo.

Suggested response

Reduce single points of failure—spread critical skills and lighten overloaded contributors.

Coaching playbook

Symptom

Generates the complete data structure for the Resource-Issue Sankey diagram. This is a computation output rule (no finding) that computes the bi-directional flow between team members, issue types, epics, and workflow stages. The diagram shows: who works on what epics, what proportion of each person\'s effort goes to each type of work, and which issues flow through which people as they progress through stages. Precious (bottleneck) resources are visually highlighted by flow width. // SOURCE NODES: team members (grouped by tribe/squad if configured) // TARGET NODES: epics, then issue types, then workflow stages // EDGE WEIGHT: hours_logged by person to issues in that epic/type/stage

Why it matters

When "Sankey Flow Data — Resource-Issue Assignment Map" keeps appearing, the team is signalling a repeatable process gap. Left unexamined, the pattern hides where work really stalls and makes improvement metrics harder to trust.

What you can achieve

Reduce single points of failure—spread critical skills and lighten overloaded contributors.

Facilitation questions

  • What system change would stop "Sankey Flow Data — Resource-Issue Assignment Map" from firing again?
  • What do the cited issues have in common — same root cause or same workaround?
  • Who owns the two-week experiment and how will we verify on the next import?

Run this rule against your own tracker data with Flow Analyzer.

Product tourSign in
RA-09: Sankey Flow Data — Resource-Issue Assignment Map — FlowAnalyzer