Investment Hours vs Resource Allocation

Allstacks offers two metric variants that estimate real-world engineering effort. Those metrics are called Investment Hours and Resource Allocation. They both rely on the same algorithm. Investment Hours shows effort in terms of hours Allstacks estimates each contributor has spent based on their activity in connected tools, and Resource Allocation takes those hours and multiplies them by salary information to turn those hours into an estimate of the actual cost to the business of the work done.

How it's Calculated

Allocation is measured in full-time engineers/employees (FTEs). FTE’s is a calculation of the ratio of time spent on a given piece of work in a day multiplied by the average daily salary for engineers at your company.

The calculation goes as following:

First, for any given day we find all actions a given user has. Actions include any commits or card activity that user has. Note: We skip weekends when considering a users FTE’s. This means that for any given week, a user can have a maximum of 5 FTE’s.

Then, we loop through the list of actions and run a calculation to find that actions FTE ratio.

current = timestamp in seconds of the current action

previous = timestamp in seconds of the previous action

first = timestamp in seconds of the first action that day

last = timestamp in seconds of the last action that day

time_spent = (previous - current) or seconds between the current action and the last action
total_time = (last - first)        or total seconds worked that day

blended_rate = average yearly salary for an employee. Defaulted to 100k.

days_worked = average number of working days in a year. Defaulted to 260, but can be configured to account for things like average vacation days taken.

daily_salary = blended_rate / days_worked

FTE Ratio = (time_spent / total_time) * daily_salary

An Example:

User Tim spent 8 hours working on a Monday. In that time, he committed twice and moved 2 tickets across his Jira board. The table below describes what actions he made, and when they took place.

For the algorithm to calculate FTE would be as follows:

total_time = (5 pm - 9 am) = 28800 seconds

daily_salary = 100k / 260 = $384

commit_a:

time_spent = (12 pm - 9 am) = 10800 seconds

FTE Ratio = (10800 / 28800) * 384 = $144 spent on that commit

card_action_b:

time_spent = (12:02 pm - 12:00 pm) = 120 seconds

FTE Ratio = (120 / 28800) * 384 = $1.6 spent on that commit

card_action_c:

time_spent = (12:04 pm - 12:02) = 120 seconds

FTE Ratio = (120 / 28800) * 384 = $1.6 spent on that commit

commit_b:

time_spent = (5pm - 12:04 pm) = 17760 seconds

FTE Ratio = (17760 / 28800) * 384 = $236.8 spent on that commit

Rolled up by card:

card_a = ($144 + $1.6) = $145.6

card_b = ($236.8 + $1.6) = $238.4

How Allocation can be Valuable

1. Allocation shows information in terms all stakeholders can understand

   1. Stakeholders don’t always know how many card actions or commits per day to expect. However, often they do know how much they’ve budgeted for things, and how many working hours they’re expecting to get out of their teams.

2. Allocation normalizes data across teams that work very differently

   1. Metrics such as velocity, commits, and PRs skew toward teams that do smaller increments more frequently. Just because a team does twice as many tickets doesn’t mean a team does twice as much work. Allocation smooths this out so teams can be compared to one another or aggregated together more effectively

3. Allocation can be a zero-effort replacement for time tracking

Areas for Improvement

Tier	Description	Notes/Questions
1	RBAC to control who can see this metric	We are establishing temporary work arounds to enable experimentation The permanent fix for this will take more research and definition to figure out how this factors into our RBAC regime.
1	Commits are not linked to tickets correctly e.g. This developer is showing as ~50% categorized in Allstacks, this is due to those missing linkages between tickets and Commits. n.b. Merge commits should be connected to tickets as well. That said, they should be filtered out in most cases.	Queued up to be resolved.
1	Establish a maximum amount of time attributed to an action after a long time of inactivity.  e.g. On a Monday, A developer takes an action which begins attributing time to that ticket, they take the rest of the week off. Time is still being attributed to that ticket.	What do we think that maximum should be?
2	Shuffling tickets in a backlog shouldn’t count as working on those tickets e.g. I move a ticket up in the backlog and take lunch. This action took seconds, but time will be allocated to this ticket until their next action
2	First action of the day needs to receive a minimum credit
2	Pull request activity should be counted and properly linked
2	Weekend activity should get credit when it happens, otherwise weekends should be ignored	Right now, are weekends counted?

Best Practices

1. Filter out the Merge Commits from this metric.