Automated Time Tracking
- James Seabrook
Premise
Time tracking is important for tickets for two reasons:
See what sort of time things took from a support point of view.
See what sort of time projects took against their estimate.
Uncertainties in exist in automation because of deviations from the ticket being worked on and therefore a potential for inaccuracy of data. However support based tickets which are atomic can be generally seen as fairly short duration and far me likely to be accurate.
Process
In any event there is a way to do semi-automation as detailed here:
For a given time period, download all the tickets which have had their history status changed from an development “In Progress” status to something else.
For each change where the development status was set from “In Progress” to something else, calculate the time between the time it was set to “In Progress” and then set to the subsequent ticket. This is the calculated duration of development effort on the ticket. The caveat is that not all that time may have been spent on that ticket. There could have been meetings, other tickets to look at, etc.
List the tickets and the accumulated duration for each change in status.
Also include any previous records of the time worked on the ticket in Jira. The reason for this is that time could already have been added and that should be included when looking at the duration. It is important only to add the incremental amount of time between the last update and and subsequent time working on it. This value should be suggested from a calculation of duration of development in progress for each occurrence of the ticket moving to “In Progress” since the last time update recorded in Jira.
Presentation to the user could be a simple google sheet at the end of the day with the tickets worked on requesting a value to be entered, with the default shown as calculated above. The tickets to show could be deduced taken from status updates (were previously or are now “In Progress”) and allowing an amount of time to be added.
At some stage development tickets will need to have time added.
On a regular basis, with the interval to be defined, produce a report on the amount of time spent on all tickets.
Update the time spent with the value in the Time Spent column, which could be amended by a user possibly from google sheets, excel or any similar software.
Person | Ticket# | Status Change | Date/Time to WIP | Date/Time to new Status | Time Spent |
|---|---|---|---|---|---|
Mark | SWMS-3201 | WIP → QA | 01/06/2021 10:30 | All previous “In Progress” | 2h30m |
Mark | SWMS-3201 | WIP → Blocked | 01/06/2021 10:30 | 1/6/2021 11:45 | 75m |
Mark | SWMS-3201 | WIP → QA | 03/06/2021 10:30 | 4/6/2021 12:00 | 7h |
Mark | SWMS-3202 | WIP → QA | 05/06/2021 10:30 | 5/6/2021 13:00 | 2h |
Cells with blue writing show defaults. Values need to be entered.
Technology
The availability of this sort of functionality seems to be sparse. There is a possibility to access the database directly using SQL however this is not assured as schemas can change. The best way to do this is through the API which provides a model.
The model can probably found through API documentation and it is possible to use Python to query the data by traversing database/object style models. Here are some potentially useful links and information found on the internet:
Internet Search Results to help
jira = JIRA(options, basic_auth=(USERNAME, PASSWORD))
issue = jira.issue('FOO-100', expand='changelog')
changelog = issue.changelog
for history in changelog.histories:
for item in history.items:
if item.field == 'status':
print 'Date:' + history.created + ' From:' + item.fromString + ' To:' + item.toString
https://developer.atlassian.com/cloud/jira/platform/getting-started-with-connect/
https://community.atlassian.com/t5/Jira-questions/Is-it-possible-to-get-the-issue-history-using-the-REST-API/qaq-p/510094