How Span links and attributes work across allocation and cost capitalization

Span connects commits, pull requests, issues, epics, and initiatives to decide where each day of effort belongs. This article explains that chain, what "Unlinked" and "Uncategorized" mean in each report, and why Workstreams, Allocation, and Cost capitalization totals can differ.

Why it matters

Effort Span can't attach to an issue or epic lands on an Unlinked row. In cost capitalization, that row starts Uncategorized, so a large Unlinked share means effort your finance team still has to classify. Knowing how linking works tells you where the gaps come from and how to close them.

How it works

1. The linking chain. Span follows this chain for every piece of work:

commit or review → pull request → issue → epic → initiative

• Commit to pull request: only commits on a pull request count. Direct pushes with no pull request add no effort.

• Pull request to issue: Span uses the links your issue tracker reports between issues and pull requests. For Jira, that's the pull requests listed in the issue's development panel, or, when Span turns it on for your organization on request, the issue's remote links to pull requests. Span doesn't search pull request titles, branch names, descriptions, or commit messages for issue keys itself. A pull request with no linked issue is "unlinked."

• Issue to epic and initiative: Span reads the parent hierarchy from Jira. An issue with no epic, or an epic with no initiative, is unlinked at that level.

2. Each day is split across the work touched. A person's active day is worth 1.0 FTE-day. Span splits it across the issues and unlinked pull requests they touched. A pull request linked to an issue counts as part of that issue. An item the person only reviewed weighs half as much as an item they worked on. Every report starts from these same daily shares.

3. Each report places the shares in its own way.

Raw or refined workstreams? Raw mode classifies Span's own top-level workstreams, so you can start without any setup, but the list can shift as Span regroups work each week. Refined mode classifies your own project list, built by mapping workstreams to projects in a refinement period. It's steadier, needs mapping work, and is required if managers approve effort each cycle.

4. Uncategorized means "not decided yet." In cost capitalization, a container with no status is Uncategorized. That happens when:

• The epic, initiative, or project is new and nobody has set a status.

• Span syncs a Jira field, but the epic's value isn't in your Capitalized or Uncapitalized value lists.

• The row is an Unlinked, Not mapped, or Out of cohorts row. These always start Uncategorized.

5. Classifications update on sync. When an issue moves to a different epic in Jira, or an epic's mapped field changes, Span picks it up on the next Jira sync. A status you set by hand in Span stays in place and beats the Jira value.

How to reduce unlinked and uncategorized work

1. Link pull requests to issues. Make sure your Git host is connected to your issue tracker so pull requests show on their issues. In Jira, that usually means installing your Git host's Jira app and including the issue key (for example, ENG-123) in the branch name or pull request title, so the pull request appears in the issue's development panel. Track progress in the PR Link Rate report.

2. Put issues under epics, and epics under initiatives, if you classify by epic or initiative.

3. Finish your Jira value lists. In Settings → DevFinOps, add any new values of your status field to the Capitalized or Uncapitalized list.

4. Decide how to treat the Unlinked rows. Set an Unlinked row to Uncapitalized to count that effort as non-capitalizable, or to N/A to exclude it and redistribute it onto each person's other work. Unlinked rows can't be marked Capitalized.

5. In refined mode, map the remaining workstreams and add anyone listed under Unassigned people to a cohort.

Things to know

Why the reports can show different totals

• Out-of-office days. With an OOO source connected, cost capitalization drops effort on OOO days. Allocation reports don't.

• Hidden exclusions. If cost capitalization is set to "Redistribute where possible, otherwise hide," excluded time that can't be redistributed leaves the totals. A banner shows how many FTE-days were lost.

• Approved effort. With supervisor-approved FTE-days, cost capitalization uses what managers approved instead of Span's inferred effort.

• Report filters. Labeled investment leaves out unmatched issues when the Other category is off. Workstreams shows the top 80% of work by default.

• Timing. Workstreams show data up to the latest weekly run. Cost capitalization and allocation update as new activity syncs.

Apart from these, every report divides the same daily FTE-days, so the totals should match. If they don't, contact support.

Worked example

On Tuesday, an engineer commits to a pull request linked to ENG-5, under Epic A (Capitalized, 100%). She also reviews a teammate's pull request that has no linked issue.

• ENG-5 has weight 1.0 and the review-only pull request has weight 0.5, so ENG-5 gets 0.67 FTE-days and the review gets 0.33.

• In cost capitalization by Epics, Epic A shows 0.67 Capitalized. Unlinked Pull Requests shows 0.33 Uncategorized.

• If you set Unlinked Pull Requests to Uncapitalized, the 0.33 counts as Uncapitalized.

• If you set it to N/A with the default exclusion setting and a By Day window, Span moves the 0.33 onto her other work that day, so Epic A shows 1.0 Capitalized.

• In Workstreams, the 0.67 goes to ENG-5's workstream and the 0.33 to the reviewed pull request's workstream, or Unlinked if Span couldn't place it. Her day totals 1.0 in every view.

Related articles

Introduction to Cost Capitalization

FTE & FTE-d Calculation

Allocation Guide: Refining Your Workstreams

PR Link Rate Report

Jira Integration

Need help?

Contact your Span account team or reach out to support@span.app.