When an existing work item (Task) already has a non-zero Actual (hours) value specified directly in ADO (not Timetracker), and a subsequent work log entry is created using Timetracker the Actual value is updated to reflect ONLY the Timetracker work log total - destroying the previous Actual value.
Related - what would happen if a user's 500/1000 work log limit is reached - are only visible work log entries considered for the Actual calculation?
Expected: Actual is treated similar to Remaining where the stored value is adjusted by the work log value. Not overwritten from Timetracker log entries.
-
Hello Christian,
Thank you for reaching out to us. Is this Actual field a custom field that you are using for Work Item Automation? If yes, then depending on how you have configured it, it is expected that Timetracker worklogs will overwrite it, as you can read about it here: Work Item Automation.
A possible workaround for you to use is to enter the value that you have in the Actual field into Timetracker in the form of time tracks, that way it will overwrite with the expected value. You can also send me a screenshot of how you have set up your Work Item Automation to see what the Actual field is used for.
The worklog limits of 500/1000 are taken into consideration for the calculation, meaning, that if you exceed the limit, only the last 1000 worklogs will be taken for the calculation.
Best regards,
Vanja -
Hi Vanja
Apologies for not being clearer before. The Actual field is the default "Actual" field shown on the Task work item type in Azure DevOps (Agile process). Looking at the Agile template the field is called "Completed Work" and our Work Item Automation is set to use "Completed Work" (recommended).
It works great when exclusively using Timetracker, but the way it is working today risks data loss. When starting from non-zero "Completed Work" value, or someone manually adding time to "Completed Work", it is simply wiped out/overwritten by Timetracker at the first update. Thank you for sharing that link as it does mention this behaviour - pity it's not highlighted in red in the application before enabling it given the risk of data loss.
Considering that Timetracker successfully handles "Remaining Time" by simply altering the field value (increase/decrease) it makes little sense to have different behaviour for "Completed Work". Given the potential for calculation scope to be limited by work log limit, it creates even more opportunity for lost/incorrect "Completed Work" on long-running/internal work items. Maintaining times (remaining/completed) should be intuitive and consistent.
I maintain this is a bug as it goes against expectation, there is no warning about data loss (in the application), and there is proven data loss (easy to reproduce). What reason could there be for this to be a 'feature'?
Regards
-
Hi Christian,
Thank you for your feedback. We will consider how to improve the Completed Work field description on the Work Item Automation Settings page.
However, it is expected that the value entered manually into the Completed Work field will be overwritten with the data entered into Timetracker, since once Work Item Automation is enabled, and the Completed Work field selected, this field is used for filling the time tracked within Timetracker. So anything that is not entered into Timetracker will not be included. Hence we do not consider this a bug but instead expected behavior.
For this reason you should adjust your internal processes and have your team only enter time into Timetracker for it to be reflected both in the Completed Work field as well as Timetracker Reporting. Your team should not be manually entering time into the Completed work field.
And as a workaround for the work items where the Completed Work field already has a value, we would recommend entering this value via Timetracker in the form of tracked time on the specific work items, in order for this time to be contained in the Completed Work field.
Once more suggestion that we have is that you might want to submit a feature request here on our Community pages and describe your use case.
Our development team monitors these requests and prioritizes them in our backlog for potential future inclusion in Timetracker.
Please let me know if I can help you any further.
Best regards,
Vanja
Please sign in to leave a comment.
Comments
3 comments