Work Time Attribution

How does minware translate calendar time to work time?

There are 168 hours in a week, but only a quarter of those are active work time. To provide hour-level accuracy, minware looks at each person's activity history to see which times of day and days of the week they are most active.

It then distributes 5 work days throughout the week based on when users are typically active, and uses that distribution to compute the amount of active work time associated with a given time interval. For example, if a person typically works 9 AM to 5 PM, a work block from 9 AM to 1 PM will be assigned a half of a work day.

minware's patent-pending time model automatically accounts for time zones and work schedules to give you the most accurate picture of how people spent their time, allowing you to do things like assess estimate accuracy for individual small tickets.

How does minware compute coding vs. non-coding time?

minware uses each person's commit history to determine when they were coding and what they were working on. Because each commit only represents the end of a work block, minware associates the time between commits with the commit that follows, excluding any meetings.

However, because people are not always coding, minware limits the amount of time that it links to a commit to 1 work day. So, if any time in excess of one work day between two commits is treated as non-coding time. For example, if you commit today and two days from now, the first half of that time block will be treated as non-coding, and the remainder will be treated as coding. This is based on the assumption that people generally commit every day.

Does minware attribute any non-coding or untraceable time to tickets?

For most metrics including estimate accuracy and sprint insights, minware will not count any non-coding time or coding time on commits that are not traceable to any ticker. However, for the time allocation and capitalization report, minware will do its best to determine what which ticket each person was working on at any given time so that you can correctly account for it in cost reporting.

Will minware ever miss commits?

minware properly handles squashes, rebases, and commits on unmerged branches, so any commit that the server sees minware will see too.

However, it is possible for a developer to rebase or squash commits on their local system without ever pushing the original commits. In this case, both the server and minware will not be able to see these commits and they will be treated as non-coding time.

How does minware handle commits that aren't pushed for a long time?

Developers can also make commits locally and wait multiple days before they push them to the server. minware will properly handle these because the time is recorded when the developer makes the original commit.

The caveat here is that these commits will not show up in any reports until they are pushed to the server. So, coding time may fill in later if developers wait a long time to push their commits.