FTE & FTE-d Calculation
Last updated: October 27, 2026
FTE-days are Span's unit of engineering effort. This article shows how Span turns commits, merges, reviews, and ticket activity into FTE-days and FTE, with a worked example for one person and for a team.
Why it matters
Every allocation view in Span (Inferred investment, Labeled investment, Workstreams) and every Dev FinOps program (Cost capitalization, R&D tax credits, R&D grant treatment) uses the same FTE-day rows. Once you know how one person's day is split, you can check any number in those reports by hand.
For engineering leaders: see where effort went without asking anyone to fill in a timesheet.
For finance: reconcile allocation, workstream, and capitalization totals because they share one unit.
How it works
1. Span collects work events. For each person, Span records these events from your Git host and issue tracker:
Commit: a commit on a pull request, credited to the commit author. Merge commits and direct pushes with no pull request don't count.
Merge: a merged pull request, credited to the pull request author.
Review: a review submitted on someone else's pull request, credited to the reviewer. Reviews count by default.
In Progress day: each weekday an issue sits in an In Progress status, credited to the person assigned at that time. Span stops counting 14 days after the issue's last move into In Progress.
Straight to Done: an issue that moves from To Do straight to Done counts on the day it moves.
2. Span groups events into items. All of a person's events on one issue that day form one item. A pull request linked to an issue counts as part of that issue. A pull request with no linked issue is its own item.
3. Span splits the day. Every day a person has at least one event is worth 1.0 FTE-day. Span divides it across the items they touched. Each item gets a weight of 1.0, or 0.5 if the person only reviewed it that day. An item's share is its weight divided by the day's total weight.
FTE-day share of an item = item weight / sum of that person's item weights that dayA day with only reviews still totals 1.0 FTE-day. The half weight only matters when the person also did other work that day.
4. Span adds up the rows. FTE-days for a category, workstream, team, or person is the sum of the daily shares in the date range you select.
5. FTE (people) divides by every calendar day. To express effort as an average headcount, Span divides FTE-days by the number of calendar days in the range, weekends included.
FTE = FTE-days / calendar days in the selected rangeSetup
FTE-days need a connected Git host and, for issue activity, a connected issue tracker. Admins with the Manage Investment permission can change two options under Settings → Investment → Choose How to Calculate FTEs:
Include PR reviews in FTE calculations (on by default). Turn it off to count only direct work on issues and pull requests.
Weight FTE days by calendar availability (off by default; appears when a calendar integration is connected). When on, Span reduces each active day by the person's calendar time, meaning meetings and out-of-office blocks, with overlapping events counted once: a day counts as
(8 − calendar hours) / 8, with a minimum of 0.1.
Things to know
Span counts days, not hours. Any activity earns a full 1.0 FTE-day split across the work touched. Span doesn't read logged hours, story points, or lines of code to size effort.
A day with no activity counts zero. Vacation, onboarding, and meeting-only days add nothing, so FTE usually runs below paid headcount.
Weekend work counts as extra. Commits, merges, and reviews on Saturday and Sunday add FTE-days. In Progress days and Straight to Done moves only count on weekdays.
Long-running tickets stop accruing. An issue left In Progress for six weeks earns In Progress days for 14 days after its last move into In Progress. Commits and reviews on its linked pull requests keep counting.
Work on epics and initiatives themselves doesn't count. Activity on the stories and tasks under them does.
Days follow Pacific time. Span groups activity into days using the America/Los_Angeles time zone, so an early-morning commit in Europe or Asia can land on the previous day. Weekly and monthly totals rarely change.
Non-coding roles. Managers, designers, and PMs earn FTE-days through reviews and through issues assigned to them while In Progress.
Worked example: one person, one week
Tom works on two categories, New features and Bug fixes, from Monday to Sunday.
Day | Tom's activity | Bug fixes | New features |
|---|---|---|---|
Mon | Commits on and merges a PR linked to Issue 1 (Bug fixes) | 1.00 | 0 |
Tue | Only reviews a teammate's PR for Issue 2 (New features) | 0 | 1.00 |
Wed | Issue 3 (New features) is In Progress; merges a PR for Issue 4 (Bug fixes) | 0.50 | 0.50 |
Thu | Commits on a PR for Issue 5 (Bug fixes); reviews a PR for Issue 6 (New features) | 0.67 | 0.33 |
Fri | No activity | 0 | 0 |
Sat | Merges the PR for Issue 5 (Bug fixes) | 1.00 | 0 |
Sun | No activity | 0 | 0 |
Total | 3.17 | 1.83 |
On Thursday, Issue 5 has weight 1.0 and the review-only item has weight 0.5, so Issue 5 gets 1.0 / 1.5 = 0.67 and the review gets 0.5 / 1.5 = 0.33.
Tom has 5.0 FTE-days for the week. As FTE over the 7-day range: Bug fixes 3.17 / 7 = 0.45, New features 1.83 / 7 = 0.26, total 5.0 / 7 = 0.71.
Worked example: a team
Tom (5.0 FTE-days), Anna (4.0), and Steve (6.0, including weekend merges) give the team 15.0 FTE-days for the week. Over 7 calendar days that is 15.0 / 7 = 2.14 FTE for a team of three.
Related articles
Understanding FTE Days in the Workstreams Report
Introduction to Cost Capitalization
Need help?
Contact your Span account team or reach out to support@span.app.