Time Model

A core part of minware’s Development Work Intelligence Platform is our patent-pending time model, which uses a combination of ticket and code activity to determine how people spend their time at hour-level accuracy without manual time logging.

With this time model, we offer two ticket/code attribution methods that show up in various reports:

• Dev Work Time - This is time spent actively working on code. It is directly tied to commits. It is then linked to a ticket only if there is an explicit ticket ID in the commit, branch, or pull request. Dev work time is useful for scenarios where you only want to include active work time, such as looking at ticket estimate accuracy.
• Assignee Work Time - Assignee work time is a superset of dev work time that further includes overhead between active code work, and further links code work without a ticket (e.g., commits to a main branch) to the most likely ticket. Assignee work time starts by including dev work time, and then attributes gaps based on the most likely ticket for the author based on signals from the ticketing system. The resulting ticket attribution will generally link 100% of each person’s time to some ticket, except when they have no ticket activity for an extended period of time. This metric is useful for things like allocating salary costs to projects where you want 100% allocation.

Converting Wall Clock Time to Business Days

As part of the time model, minware translates the 7 calendar days each week into 5 business days.

It does this by first dynamically building a schedule for each person based on the hours of the day they are most active derived from commit activity. Each hour of the day gets a percentage weight so that a 24-hour period adds up to one. However, if someone strictly works 9-5, then a time period 9-5 will equal a whole day, as the weights for other hours in the day will be zero. If they work evenly 9-5, then half that interval (e.g., 1-5) would equal half of a day.

The time model then considers how active people are on weekends vs. weekdays to assign percentage weights to days such that the percentage weights for each of the 7 days in the week add up to 5 to represent 5 business days. If someone typically works quarter days on Saturday and Sunday, then a time interval on the weekend would equal one quarter of the business days of the same interval during the week.

This model assumes that each person works a 5-day full-time week. If people work a different number of days, their time will be scaled to 5 business days per week.

After applying this weighting conversion, we arrive at Dev Days and Assignee Days values, which add up to 5 per week if the person is fully active.

Attributing Time to Commits

minware’s dev work time model attributes time to commits by allocating the time between two commits to the commit that follows. For example, if commit B happens four hours after commit A, then those four hours of time will be attributed to commit A. This can be seen in the following illustration:

minware also excludes meetings when linking time to commits. So, in the previous example, if there was a 1-hour meeting in the middle of that 4-hour interval, then only 3 hours would go to the commit, and the hour for the meeting would not be counted.

minware also limits the time it allocates to each commit at up to one business day, with the assumption (which has been validated in large-scale testing) that developers generally commit their work at the end of each day, which is a generally accepted best practice. If specific developers are not doing this, then their time may be under-counted.

Computing the Most Likely Ticket

For meeting time, time that does not fall within one business day of a commit, or time linked to a commit without a ticket, the assignee work time model falls back on the most likely ticket that the person was working on during that interval.

The most likely ticket matching uses a few different heuristics to attribute time intervals to tickets:

• First, it looks for all tickets that are in progress while assigned to the person, or up to 30 days leading up to a ticket being moved directly from to-do to done as if it were in progress.
• Then, if there are multiple in-progress tickets, it chooses the one that was most recently moved to in progress while assigned, or assigned while in progress, favoring epics first with the assumption that epic tasks are more likely to be long-lived than non-epic tasks, which are typically interruptions.
• If there is no in-progress ticket, then it will look for a ticket created by the author (favoring epics first) on the current day since creating a ticket signals that the creator worked on it in some capacity. (This allows us to allocate time to people who focus on creating tickets like product managers.)
• If there is not otherwise an active ticket on a day, then the model will look back up to 7 days for the most recently active ticket, favoring epics first and then picking the most recent ticket in the past 7 days. This is based on the assumption that people are most likely to be wrapping up their previous work until the next task has started.

If a person has an out-of-office event on their calendar, then the assignee work time model will not attribute that time to any ticket (assuming there are no commits while out-of-office, which are counted) and consider it untraceable.

Otherwise, 100% of people’s time will be allocated in this model unless they have been completely inactive for more than 7 days.

The assignee work time model further uses a computed start date, and a computed end date for people who have left the organization (no activity for 30 days), and not count any time before or after a person’s employment.

Handling Squash/Rebase Commits and Delayed Pushes

minware properly handles squashes, rebases, and delayed pushes, so we will see any commits that the server (e.g., GitHub) eventually sees and factor those into the time model. If a commit is pushed at a later time than it is made, then the reports will backfill the activity.

The only time when minware cannot see commits is if they are squashed or rebased locally and never pushed to the server, which is generally a bad practice because it loses some of the change history

Time Fields in Reports

Custom Report

The custom report has both dev and assignee work time fields. The dev and assignee business day metrics are available as Dev Work Days and Assignee Work Days.

The custom report also offers Dev Work Months and Assignee Work Months, which represent the portion of Dev Work Days and Assignee Work Days divided by the total number of business days in the current month, respectively. This is useful for accounting when multiplying this value by a monthly salary cost, as different months will have different numbers of business days.

The custom report further includes Dev Calendar Days and Assignee Calendar Days, which use the dev work time and assignee work time model, but do not apply the conversion from wall clock time to business days, so there will be 7 days in a week and weekend/overnight time will count the same as time during the work day.

Additionally, the custom report has Logged Days, which is based on actual time logged in the ticket tracking system divided by 8 hours. This field does not use any weighting or time model, but can be helpful for comparing time log data if it exists to the time model outputs.

Sprint Stats

The sprint stats report offers Dev Days, All Days, and Logged Days, which are exactly equivalent to Dev Work Days, Assignee Work Days, and Logged Days described above for the custom report.

Time Allocation Report

The time allocation report uses the assignee work time model, which allocates all traceable time (only excluding vacations and extended periods with no ticket activity) to a ticket. Time that is not spent actively coding is represented in different ways depending on the report mode:

• By Capitalization – The report shows all traceable time by capitalization status and also displays untraceable time for people in gray.
• By Velocity – Time that it not dev work time is shown in light blue as “Non-Coding”.
• By Coding Time – Time that it not dev work time is shown in light blue as “Non-Coding”.

Scorecard

The scorecard report displays all of its time-based metrics in terms of dev work time. The exception is if you do not have a version control system hooked up as a data source, in which case it falls back on assignee work time.

Other Reports

All other minware reports use the dev work time model when displaying dev days, and may show time between active work intervals as “non-coding time.”